Category: Articles

Home Articles ()

Pilot Projects – Do they need Air Traffic Control?

air traffic controlAhh the pilot project. It’s a term that software sales people hate to hear but almost every major software implementation project works its way through this phase. Even I have recommended using pilot projects as a safe way of determining the suitability of software for a particular purpose.

The notion of a pilot project isn’t new. The idea is to implement the entire software solution being proposed on a minor scale with real data to see if it can meet the needs of the organization. Often, just like in drug testing, there is a ‘control group’ and a ‘test group’. These groups are best organized as similar sized departments with a similar workload. The test group will use the new system, the control group will continue with normal procedures. At the end of the pilot, the performance of both groups will be evaluated and the relative efficiency of the new system can be measured.

It’s a great plan. After all, the only change between the two groups will be the introduction of the new software so the effects should be easy to test. For people who have just finished their MBA and are now working in the middle-management ranks, this provides perhaps the only opportunity to determine a Return on Investment (ROI). This is particularly difficult to come up with otherwise with certain systems such as project management software where the hard-cost benefits are difficult to determine and the soft-cost benefits such as bringing in the project early are tough to prove in advance.

The final result of the project is the identification of the right software to implement and even some tips on how to implement it. All of this at little to no cost, right?

So, if it’s such a great plan, why aren’t more pilot projects successful? Often a pilot project is undertaken only to find out that the results are never tabulated or that the results are delivered but they result in no decision or that the project is terminated prior to completion.

There are a number of hidden challenges in a pilot project which must be dealt with if you are to have any chance of success.

First of all there is a fundamental underestimation that I find in almost 100% of pilot projects which I encounter. Often the software itself for such a project is offered for little or no cost and the assumption is then made that the cost of the pilot project is therefore zero. When we’re talking about an enterprise system, nothing could be further from the truth.

In order to see the results of any enterprise software system, it must not only be installed, it must be implemented. As anyone who has done such an implementation can tell you, the costs of installation and purchase of the software are often dwarfed by the size of the rest of the implementation budget. There is legacy data to be configured and uploaded, the configuration of the system to be determined, reports and entry forms to be created or adjusted, training, more training, external systems to be linked, practices and procedures to be created then adopted and, (did I mention?) more training.

This is so whether you are looking to try the system out on one week of data or one out of fifty projects or one out of 20 departments.

Once a system has been implemented, expanding its use to the rest of the company is an incremental cost which is the least costly and least effort of the project overall.

An implementation of an enterprise system of almost any kind for the first department or first project or first core element of an organization may be scheduled to take weeks, yet, so many organizations that I speak to talk about a pilot project like it will take a week of effort and will cost the organization nothing.

Without an understanding of how much effort such a pilot will really take, management can quickly become frustrated and your sponsorship of the project will be in jeopardy.

Even if there is adequate management support, there are a few other pitfalls to overcome. First of all, it is ongoingly stunning to me that almost no pilot projects I encounter actually have metrics, for how the test will be measured. I see this over and over and over again. When pressed to how the pilot team will know that the test was a success (or even if it’s complete) the general feedback seems to be “We’ll know.” As though some feeling will be imparted to the team when the system is good enough.

Also, for the test to be fair, there should be no other influencing factors that would mask the effectiveness of the system in question. That’s great but in today’s business environment, everything is changing all the time. And actually isolating a team to avoid such influence would be an unnatural influence by itself.

It’s also worthwhile to mention that the implementation of any significant change in the systems of a group almost always results in a short-term drop in performance as the personnel adjust to a new way of doing business and as the analysis or data from the new system is integrated into the group’s decision making process. Very short term implementations such as a pilot program may show negative results where a longer term perspective might show a better example of the potential benefits.

So, is it hopeless, are you now reduced to choosing software from the description on the side of box? It’s not quite that bad. For some types of software, it is easier to implement a pilot than others. If we take project scheduling systems, for example, it is relatively easy to have one department work with one tool while the rest of the organization works with another. You can even have implementations done by staff who have been previously familiar with different tools to show how they can be put to their best advantage.

For other types of software, however, pilot projects may not be your most effective evaluation method. You might use other tools such as reference site visits or the use of an independent consultant to help shape the overall implementation plan. This cost and effort would be recoverable regardless of which system is ultimately selected and is often very revealing to the internal cultural issues that will need to be overcome to take advantage of the enterprise system in question.

One way or the other, the most important thing to remember: pilot projects aren’t free. Make sure you’re getting a good return on investment on the effort and money that the pilot itself will cost.

Project managers don’t always manage from the top

project_managementThere’s been a lot of project management going on in our office lately and it’s allowed me to do something I usually don’t make enough time for and that’s training project managers. To add to this already interesting task, I had the privilege of addressing McGill University’s project management students this week and found enough commonality between my staff and the McGill students that I thought I’d share it with you.

It seems to be almost universal that when a new project manager starts to manage projects that they are firmly convinced that if only they were in charge, everything would be fine. I watched 2 students this week working on an assignment in class just prior to my lecture where they were asked to organize a company in such a way as to make the project management as effective as possible. Oh if only it were so easy.

These students were worrying the company’s organigram trying to ensure that they would have sufficient authority to effect the changes required. Sure enough, the first question posed to me by the students in class was the first posed to me by my own 2 new project managers inside our firm; “How does the project manager get past the interference (sorry I meant help) of management?”

If you’re a manager and are now getting hot under the collar, you’ve probably heard this before. New project managers seem to always confront this difficulty and those that cannot resolve it don’t remain project managers very long. In an organization, which does more than one project, the most common structure for operations is a Matrix organization where project managers are responsible for specific targets, which we measure in work output and line or resource managers are responsible for the departments whose employees must deliver that work.

The resulting conflict between resource managers and project managers is inevitable and perhaps healthy but for those who think that their perspective is most important, it can be intensely frustrating.

The project manager trainees who I’ve been working with this week wanted to know how they were to acquire the authority to overrule all those resource and line managers in order to accomplish the projects they would be assigned. It was left to me to deliver the bad news. With the possible exception of mega projects where there is only one project going on at one time, project managers are almost never given such authority and it doesn’t take much thinking to see that they shouldn’t be either. Left to their own devices, a project manager would burn staff out. Oh, they’d take care of them for their own project of course, but there would be no allowance for the rest of the employee’s life. If a staff member is absent for 4 and a half days with no excuse, that’s a critical even for the that person’s resource manager. I mean, are they still working here? Are they sick, are they dead? Should I replace them? It’s a big deal. Yet, if I go to a project manager and say “Did you hear about John? He was absent for 4 and a half days last week?”, a project manager is entirely likely to ask me only about the 4 hours during which the person was present “Did they work on my project while they were here?” After all, that’s what is of interest to the project manager.

Project managers also have a horrible reputation for ignoring the requirements of other projects within the organization. When I ask what priority a particular project should have company wide, the answer from the respective project manager is inevitably “at the top”.

How then can a project manager get the resources and attention they need to accomplish the targets they have committed to? Here’s the answer I gave my staff last week. “You’ve got to plead, beg, grovel, demand, enroll, convince, ask, suggest, insist and cajole to get the resources you need. What you can’t do is instruct.”

The natural conflict that then arises between the resource manager and the project manager is one that is common to almost every high-tech company in the world. We’ve taken to using advanced technology to deal with this conflict both within our firm and recommending the same technology outside the firm. What is it you ask? A collaborative web-based tool? An on-line project resource reconciler? No. We make the managers actually talk to each other. I know it sounds trite. But it’s an element of project management which is becoming scarcer and scarcer. We setup a structure whereby the line managers and the project managers must meet on a regular basis to talk about resourcing priorities. Amazingly, they seem to resolve all outstanding resource conflicts without much difficulty on a regular basis. It’s the regularity of it that makes the biggest difference. You can have an argument if you like, but you’re going to be right back here next Friday looking at the same person with the same challenges. It’s makes for a big incentive to get along.

It’s not to say that the latest updates in project software don’t make a difference, they do. But when you use technology to replace human interaction, you do so at your peril. It’s humans after all who will have to get the work done and cooperation between staff can’t be mandated like a feature in an application.

It’s enhancing this human interaction that software is supposed to be best at rather than replacing it. Collaborative project tools are excellent enhancers when a culture of communication is already in place but if these managers aren’t ready to even talk to each other, great software features can’t make a difference.

No matter what the application is, you can’t ignore the human factor and the more of the enterprise that is implicated in a particular corporate system, the more impact the human factor has.

Path of least resistance

path of least resistanceIt’s the path of least resistance that is the root of most problems with implementing enterprise project systems. You no doubt have heard the term. It’s commonly used to describe the path water will take if put on an uneven surface. Water will always flow down the path of least resistance, forever taking the easy way to lower altitudes

In the world of project management systems, the term is an easy analogy to adopt if you start to look at enterprise systems. If you’re just looking at a desktop scheduling tool then this whole notion may not play such a key role. In this case, an individual might be willing to tackle a path that is quite difficult including a steep and high learning curve, software which is not simple to install or use and a process which must be defined by the user. An individual might take on such a system in the interests of furthering long term goals of either the company or him/herself.

But what hold true for an individual often does not work for a group. I’ve seen more and more organizations this year striving towards an enterprise project control system. Sometimes the project is underestimated (Ok, almost always) and sometimes the project has many cultural hurdles to overcome (Alright virtually always) but one obstacle that seems to virtually always appear is often not identified as a problem at all and that’s the tendency of people to follow the path of least resistance.

I’ve come across it several times in just the last month. In a huge insurance company based in the US, they have been striving for a common project management system for over a year (at least publicly – They’ve probably been trying to decide on such a system since the company was founded!).

This year I was peripherally involved in the selection process. Fundamental to this process was that a single product would be chosen. Over 300 people were canvassed as part of the due diligence process. “We didn’t want anyone to feel left out,” said one senior committee member. “We need universal buy-in.”

After almost 16 months of sometimes intense internal negotiation, they have now told the 3 product finalists that the “standard” project management tool that will be chosen must be able to integrate fully with Microsoft Project as it will continue to be used by project managers across the company whenever they feel the need is warranted.

Now, I’m on record as saying that I like Microsoft Project just fine but it must be obvious to you that choosing a “multiple-product standard” is an oxymoron.

How can an organization take two products; one a desktop planning tool, the other a high-end enterprise project control tool and make them an integrated project management system for the entire enterprise? Well, they can’t. Oh, you can declare that such a system is now your enterprise project environment but that doesn’t make it integrated.

The problem is that different people have different needs. It might be better in the long term for the organization to work with a complex but extensive project management system but end-users who don’t see a direct benefit to them won’t adopt it. They will follow the path of least resistance; choosing a system which can return them results instantly. Full-time professional project schedulers see their path differently. As an individual who is often asked for reports and analysis, they might find the path of least resistance to be in a high-end system with a lot of flexibility.

So, will this company implement an enterprise project management system? Not this year.

I’ve seen the same phenomenon at the management level. This month, while advising a multi-national pharmaceutical company, I watched a senior executive follow the path of least resistance into a no-win situation.

In this firm, the senior executive in a research group, created a committee to select an enterprise project tool. It started off with a great deal of momentum and lofty ideals. But, as many committees do, over time, the diverse interests of this group started to show through. The selection process should have been complete in a few short months. Instead, some 18 months later, it’s now more mired in controversy than ever.

The senior executive, has had several opportunities to move the process forward at the risk of upsetting some of the committee members but he won’t. He takes instead, the path of least resistance. He has always managed through consensus. His theory, is that everyone just stays in one room long enough, eventually they’ll come to the same conclusion. The underlying assumption of this theory is that there is common ground to be found somewhere. The problem is, there are different kinds of tools appropriate to different kinds of users. Consequently, the longer the committee struggles, the more each diverse interest is attracted to a different kind of tool. Without the intervention of someone senior in the process the committee has no hope of success.

So, is there any defense against the path of least resistance? There is. The two best weapons against the dangers of following the easy road into trouble are commitment and structure.

Commitment is the tougher of the two and is most likely to be seen at the executive level. If you know that you or a committee or group you are sponsoring may be enticed down the garden path of least resistance, you can keep them productive by committing to a goal that goes beyond what is easy. Kennedy did it when he committed to send a man to the moon before the end of the 60’s. When he consulted the project managers they said that the project was impossible in that time frame. But his commitment had inspired the country and many men and women toiled to make the commitment a reality even against tremendous opposition and adversity.

If you’re not the President yet you still want to make an impact in this area, you can do so with the second great weapon; structure. Even the lowliest project system selection committee member can introduce structure into the selection process. Structure can usually be introduced at low stress without offending anyone from any faction.

Once the structure has been agreed to, it becomes a powerful backdrop against which to move the process forward. It may be one of the few elements of the group’s entire history on which everyone was able to agree and thus it can become a focal point for progress together.

Whichever method of combating it you choose, don’t discount the insidious effects of following the path of least resistance. Remember this Chinese proverb – if you don’t change your path, you are liable to end up where you are headed!

Project management is not just planning

resourcehistogram1If you’ve read this column before you may have seen me invoke my favourite project management quotation. It is reputed to have come from Napoleon Bonaparte who once said “A battle plan lasts until contact with the enemy.”

The problem with a lot of new project managers or with many newly created project management departments is that the focus stays too much on the planning process and not enough on what happens once the plan is put into action. If plans were perfect, we wouldn’t need project managers. It’d be great though don’t you think? We’d post the project schedule, and then just come back on the last day to pick up the product we’d planned.

Many organizations I visit are dissatisfied with the effectiveness of their project management process but continue to work on the details of the planning phase of the process with the notion that if the plan was just good enough, project management would improve or that if the plan had been better, the last project wouldn’t have been as late.

Project management is much more than just a great plan. The plan is important, of course but the weakest area of project management across the country that I see is often in the execution phase of the project. I’ll ask about the status of a project and hear how the project is clearly late and over budget but find that no one has a notion of exactly what elements are late or what elements have gone over budget or for how much or why.

Some of this can be explained away by a lack of communication. It’s one of the fundamental reasons I think, that collaborative project tools that tracks issues that arise during a project’s lifespan are such a hot item at the moment. Fundamentally though, the missing link is project tracking.

Project management should be a reiterative process. The results of one project should be able to be rolled into the next. We hear about this when experience project managers insist on a “lessons learned” phase after project completion but there is something much simpler that if often the last thing to be implemented in an organization’s project process. If you will simply follow the plan on a regular basis (weekly, monthly etc. based on the length of the project – and yes, this means every week.) and update the tasks with a notion of how many person-hours or person-days have been spent, what the new projected end-date is of the task and evaluate any impact on remaining tasks.

This exercise alone will give you an “as-built” schedule at the end of the project. Project managers in the construction industry are very familiar with this concept. “As-built” schedules are used in that industry to settle disputes after the project is over in that much-dislike phase of construction project management known as ‘litigation’. For those of us who don’t have post-project litigation to look forward to, the most valuable result of this exercise is to compare the as-built schedule with the original plan and find out how variant you were.

The first reaction to looking at this data is often shock followed immediately by a knowing look as though the data confirms what you’ve always suspected. The results of such analysis are often very revealing. You find out that you really do spend too much time on overhead type tasks such as meetings and that your resources are not available for project tasks 8 hours per day but more like 4 hours per day (No, I’m not kidding). Next you find out that the original estimates from the project team members who are the most optimistic were actually the most optimistic and that the actual project results were way over that plan. The converse can also be true, that the most pessimistic team members make the longest estimates.

If you collect this date, you’ll be able to return the results of have looked at it into your next planning process. You’ll be able to allow for pessimistic and optimistic attitudes. You’ll be able to look at completed projects phase-by-phase; determining if they are more or less likely to achieve the new targets for your most recent project.

This type of reiterative process is used frequently in plant maintenance type projects where the work is similar time after time and a realization in efficiency can mean virtually millions of dollars in regained opportunity cost. It is, unfortunately all too rare in high-tech projects. I know, some of you are ‘artistes’ who are certain that every project is unique and that no element is comparable to any other project but that’s mostly not true. There will almost always be some levels of similarity in projects in the same company.

If you are interested in seeing some of these results however, then you’ve got to do the toughest thing there is in implementing a project control system – you’ve got to collect the actuals. It seems like it should be the simplest thing but many project team members may be reluctant to deliver a precise accounting of the work they’ve done for fear that the data will be used against them. I know, I know, it would never happen at your organization – believe me, it happens in many, many places.

If you’re looking for a culture change that might result in a reiterative project process, then try starting with an automated timesheet that accounts to the activity level. There are a number to choose from that suit different types of requirements. Many of these systems will have extensive functionality for tracking and accounting for data but, go easy on the enforcement in the early days of implementation. Once entering the timesheet data becomes a habit you can gradually crack down on the quality of the entries. Some timesheet systems include interfaces to return data to your project scheduling system making ‘closing the loop’ even easier once you’re ready for it.

Remember, you can’t even begin a reiterative project process unless you’re collecting all the data required in the loop but for those who can go the distance, the rewards can be significant.

Giving up on a project

Dead Horse 2It goes against the grain for many of us but sometimes its right to give up on a project. The 1994 Standish Group survey report on project success called “Chaos” has been oft quoted as evidence that many projects are unsuccessful. The report noted that somewhere over 80% of projects are either cancelled before completion, do not deliver what was intended or run significant over budget or over schedule.

The report noted that about 30% of projects are cancelled and it had a couple of noted hideous examples. Recently a new survey conducted by CIO Insight magazine asked a series of different questions including whether or not the most recent project that CIO’s considered the most significant was completed successfully or not. Interestingly, over 50% of respondents said that their most significant project of the last 12 months had been successfully completed.

What is left unsaid about both of these reports is the importance of cancelling a project. The examples sighted in the Chaos report point to projects that cost millions of dollars and delivered nothing when cancelled.

There is a time to cancel a project and there are warning signs that it may be time to stop the party.

First of all, as my friend Ian Koenig once said to a group of project managers, “If the horse is dead, dismount.” He’s right. There is no use trying to help a dead horse. Some people will try to change riders or saddles or reorganize the horse. No, if the horse has expired, it’s time to get off. Mostly you’ll know when that is. There can come a point in a high-tech project where you simply know that the perceived benefits simply don’t warrant the expenditure of resources that you’re putting out on it.

‘So, is my horse dead or only lame?’ you ask. If you need some clues, here are a couple of places you can look:

The champions have left. The original sponsors of the project; the people who had the vision that started the ball rolling have moved on for whatever reason. The new sponsors have inherited this project but without the same fervour as their predecessors. It’s time to have a serious sit-down with the new sponsors and determine if they’re truly committed to what you’re in the middle of building.

Costs and Schedule are out of control. The defence industry has a great standard for dealing with variances on projects. It’s worthwhile sharing with everyone. The idea is that on a regular basis (perhaps monthly on a major project, or weekly on a shorter one) any work packages, which are way off their original plans, must be dealt with. A “get-right” plan must be implemented which shows how the project will get back on track or a change in the original schedule must be accepted that includes the impact of the changes in schedule. There should be less than a dozen of these to deal with at a time or the time required to resolve each variance exceeds the time until the next review. If you have a project which is going later and later and later or costing more and more and more, then you’ve added an element of risk that you might not be able to handle. It’s time to sit down with the project plan, scope out the real work remaining and see if you should continue or give it up.

Risks increase. If you are using risk management software, then this might be apparent in the reports you produce. For the rest of us, you’ve got to look to more physical signs of risk. Changes in personnel for example, can kill a high tech project. Any changes in the physical development environment such as personnel, management, budget or changes in the original plan such as a major scope change – perhaps because of technology is worth pausing to consider. Scope can sometimes change because more people get involved than were there at the start. Design by committee is not uncommon but it carries the potential to add risk to the project as everyone on the committee lobbies for their own pet functionality. If the project has now become much more complicated because of the increase in risk, it may no longer warrant doing.

The world has moved on. Some projects simply can’t keep up with technology. It sounded great when you started but technology is no longer where you were when you did the original design. This can result from updates in hardware, in software, in competitive products, in market perception of what it is you’re doing. You might have created a nuclear mousetrap but if it doesn’t have a web interface, you probably can’t sell it at the moment. If technology or market demand has headed out beyond your ability to keep up, then you’ve got to consider putting the project on the shelf.

There seems to be a big stigma about cancelling a project. The Standish Group considered cancelled projects to have failed. I’m not so sure that’s the right assessment. In some industries, say pharmaceuticals, it’s considered quite appropriate to cancel R&D projects, which are not expected to bear fruit. It’s not a problem, just considered a characteristic of the industry.

In a high-tech field, perhaps we should adopt some of that thinking. Highly trained (and expensive) resources should be working on projects that have a high degree of probability of success, not on projects where the final result won’t match the investment.

If you do find yourself in a position where you think it’s time to pull the plug, go about it in a methodical fashion. Pull the people involved together: management, the sponsor and the client first – then the project personnel. Make sure that that everyone understands the reasons the project should be cancelled and take care of outstanding concerns like legal or human resources issues as people and money are reassigned.

Choosing the right projects – the first step to success

7258227It’s ongoingly amazing to me. I visit companies virtually every week that have projects that are suffering. The story about why these projects are not working is often the same, sometimes different but what is almost universal is that companies on a fairly regular basis get involved in projects that are out of their depth. When I ask these companies how they selected these projects, I’m often greeted with a blank stare.

The fundamental problem is that most organizations have no process for determining the appropriateness of taking on a project or not. The decision is much more complex than doing a resource levelled analysis of all combined projects but that also is often not done. There are several aspects to be considered here and I’d like to outline a few of them here.

Fundamentally your decision breaks down to a couple of main areas: Capacity, Benefit and Opportunity Cost.

Capacity refers to your ability to actually deliver a particular project and the answer to that may not be as simple as you might think. There are some obvious factors to consider of course. For example, do you have the resources and the skills required to deliver the project? Are those resources currently involved in other projects? Resources are more than just people although people, of course are key. It also includes office space, money, materials, access to the appropriate equipment and more.

Capacity also refers however, to something more fundamental. Do you, for example, have the organizational model to support certain types of projects? For example, your IT-type firm might have done dozens of successful $10,000 projects and have access to hundreds of other resources for a project that might be much larger. However, the odds are that you don’t have a business model established that would support a million dollar project regardless of how many other programmers you know. The simple infrastructure demands of a million dollar project are simply heavier and more complex to manage than most smaller-project firms are ready for.

Capacity might also include an ability to manage or mitigate risk. A firm that had always worked on low risk projects might not have the structure or financial or skill depth required to be able to effectively function in a high-risk project.

In the cases where your capacity is not up to where it needs to be to assure a successful project, it’s worthwhile to consider a joint-venture with an organization that does have that capacity or even passing on the project altogether.

The second area to consider is Benefit. It’s not enough to say that a project can be done. A responsible project manager should consider if it should be done. What will be the return on investment for this project to the organization? What benefits will the organization realize from the successful completion of this project and conversely, what are the potential side-effects to this organization of the project being unsuccessful?

Cost/Benefit analysis is often useful here and while you’re doing such an analysis it’s worthwhile to consider the different project risks you thought about while doing your thinking about capacity. What will be the benefits for example, if a particular area of scope or functionality, which you’ve identified as high risk, must be abandoned? Also, you’ve got to factor in time. Will the expected benefit be reduced if the project is late? Often in the commercial software development world, there is a window of opportunity that has been identified by marketing that, if missed, would severely reduce the value of the tool being developed. You should be weighing that against the risk of project delay while looking at capacity.

Finally, there is an opportunity cost to be considered. Opportunity cost is the value that would have been realized if you did something else with your resources. If you’ve been looking at your high-tech investments lately and wistfully thinking of the luscious earnings of a 4% government bond that you could have invested in, you know what I’m talking about.

In the project world, you’ve already looked at whether you have the capacity to do a project and what it’s potential benefit is, but you’ve also got to look at what else you could be doing with those resources that might deliver an even greater benefit. Perhaps, for example, an organization might realize much greater total value from the successful completion of 4 or 5 smaller and low-risk projects than from the successful completion of 1 very large but high-risk project. Or, perhaps the allocation of a small number of resources to a smaller but low-priority project will put a larger and more beneficial project at risk. We recently had to suspend work on a project that was due to complete in the next 3 months that we really, really wanted in order to ensure the on-time delivery of a much larger and much more important project. It was a tough call on a tough day but one that everyone agreed would deliver better overall value to the company. A good project manager must be able to point out to management the potential projects that could be successfully completed with the resources required for whatever you are doing.

Everything we’ve discussed here has a major assumption and that is that you have established a system for evaluating the feasibility of projects in the first place. It’s a phase, which perhaps seems obvious as we talk about it but in fact, is often absent. Perhaps some project managers feel they are not given the opportunity to not take on a project or perhaps the notion of refusing a project would be considered negative or career limiting to some. If you haven’t got an environment where a project can be considered before it must be adopted, it’s worth organizing one.

I believe the project selection phase is critical and, as an executive myself, I think that a project manager who returns to me to say that they’ve considered our project capacity, the potential benefits and opportunity cost of what we’re proposing and is concerned over what taking on this project will do to the company, rates high in my book.

Enterprise Software – Integrated or Best of Breed?

BusinessPeopleA curious transformation has come over ERP sales people that I’ve been meeting for the last couple of years. No, I’m not talking about that strange affection for changing their acronym like clockwork every 6 months. The last thing I need to hear in this industry is another TLA (3-letter acronym) No, I’m talking about the newfound affection for 3rd party tools. Not so long ago enterprise sales people had only one tune to sing and that was “The only way to integrate is to eliminate all software but ours.” Now, some of us thought that was a trifle arrogant but that didn’t seem to bother ERP sales people who new that their way was the right way and were determined to prove it by eliminating all software in their path and having their clients try to work with just their own systems.

All of a sudden, these same salespeople have embraced 3rd party vendors with the fervour of the born-again crusader. “We can’t be everything to everyone” they now claim, “We are committed to a best of breed solution.”

What, I wonder has brought about this change of heart? Is it perhaps the results of the over-publicized lawsuits of failed enterprise software implementations? Perhaps resistance isn’t futile and 3rd party vendors efforts to stick with their clients are paying off.

I suspect, the new cry of the enterprise salesperson is the most likely scenario. It has turned out that it really is impossible to be everything to everyone.

As everyone who has ever designed and delivered a piece of software knows, the end result carries with it the bias of the author. The notion of a truly objective perspective in writing software is a myth. We can debate whether one package is more or less generic than another but each system carries its own ideas of how to do business. When you consider the major ERP or CRM vendors, it’s fair to say that they are the result of much feedback from the field in how they should be constructed.

But widespread feedback is not a guarantee of software that works for everyone. In fact, the more people involved in a design decision, the more likely you are to end up with something that is not useful to anyone. Software design through the consensus of a committee is a nightmare that thankfully results in very few software systems. Anyone who doubts this should try assembling a 30 person committee to work on any design issue and see what a few hours in a room delivers (here’s a hint – keep the Tylenol handy). No, the best chance for success in enterprise systems design is more likely to come from widespread feedback to a small, skilled design team who retains full authority to implement design changes as they see fit. All the more reason to believe that the result of such systems design will be a system with the bias’s of the designers in evidence.

Since such systems are being implemented in major sized organizations, the likelihood of it being able to meet the needs of the entire organization seem remote.

Also, remember, that these types of systems had to be sold. The marketing influence for an enterprise system will always be biased to what decision makers desire. Perhaps to no one’s surprise, the senior management and senior finance department personnel who are most often involved in these decisions were attended to first.

Perhaps the only surprise is that it has taken this long for the idea of a “best-of-breed” solution to be popular with such vendors to catch on. I suppose it’s the result of the length of time it takes to implement an enterprise ERP system.

There is a pattern to most of the post-implementation stories I’ve heard. The core Financial functionality implements just fine. The General Ledger, AR, AP and perhaps billing move forward without much trouble. Translating legacy data into the system proves the biggest challenge along with training the staff to work in the new system and designing and implementing new procedures to follow.

The system begins to settle in a routine and now attention turns to the secondary systems. Perhaps this is inventory or project control or time and attendance or manufacturing control. It is in these secondary systems that much more serious implementation challenges arise.

First of all, it is possible that the decision to use this enterprise software was made outside the control of the people who have been running these secondary systems. That generates resistance before the work even starts. It is also possible that the same functionality that made the system attractive for management makes it equally unattractive to end users working on secondary systems. For example, I’ve seen project management cost reports from an ERP system that were popular with management only to find that what appear to be rolled-up summary management reports are in fact the lowest level of detail permitted by the system and the tens of thousands of tasks that must be managed in the project system could never be effectively managed in the enterprise ERP.

There are many examples of such mis-matches in functionality. The old pitch for ERP systems was that everything would be integrated and it was worth trading some level of functionality for the benefit of every element of data being tied together. Out in the field however, it turns out that sometimes the cost of being integrated is by far outweighed by the benefit of using tools designed for their level of use.

It places the enterprise software vendors in a very different position. Suddenly they’re very interested in adopting partners who can integrate with their own systems. This is likely to open up access to the finance system market to mid-range players who have been unable to offer an integrated, across-the-enterprise system but can offer an open architecture finance system which is well suited to interfacing with other best-of-breed tools.

Best of breed? It sounds like a great idea to me.

Capitalization and why it matters

7621529It’s a six-syllable word, I know. It’s this week’s topic of conversation however, thanks to a recent decision by the FASB. The Financial Accounting Standards Board is not the most reckless association on the planet yet we owe many of our own Canadian Generally Accepted Accounting Principles to their initiatives. They are the US Federal group of accountants who set accounting standards for companies all over the US. In June, the FASB decreed that intangible assets must be identified during the purchase of a company.

This category of assets has always been referred to as goodwill. With the shakeup of the technical sector this year, goodwill has become something that we’re all a little too familiar with. Goodwill is the difference between what the company’s financial balance sheet says the company is worth and what was actually paid for the company.

How is this possible you ask? Well, imagine a 10-year-old software company. It has 50 people in it and has grown through its own efforts, expanding by immediately reinvesting its own profits in its own growth. The company has done this by creating and the successfully selling 2 or 3 vertical market software products. Yet, when we look at the financial statements for this company, it might not look like it’s worth anything. The expenses for the firm have risen at the same pace as the revenues, eating profits for new staff, new equipment, new marketing efforts as the money became available. The company may have some money in the bank but the true assets of the company can’t be found in the financial statements. The valuable assets are the knowledge of the staff, the ongoing nature of the revenue stream, brand recognition, the client base and, of course, the software products themselves.

So why should anyone care? Well, in a technically oriented company, what is usually being paid for is knowledge. It’s been awhile since we spoke in any good terms about the movement to a knowledge-based economy but the FASB decision is, in my opinion a welcome one for the technical sector.

With all the mergers and acquisitions done in the past 2 years goodwill was the majority of what was traded. Companies were valuated at huge numbers not based on their balance sheet but rather a series of nebulous factors that no one felt compelled to identify. Being “first-out” carried huge advantages to valuation (ask pets.com) and the existence of growth meant that we could ignore profits for the foreseeable future (remember Amazon?).

There was, no doubt plenty of conversation and speculation about the intangible values in the cigar-smoke-filled back rooms where deals were made but no specific accounting of the value was ever required when the deal was done.

The FASB decision sets a trend for everyone in this industry. Now, the value of some of these intangibles will have to be identified. In particular the knowledge-base areas of the company to be acquired will have to be quantified in some way.

So, how do you go about valuating the efforts involved in high-tech? Any business owner who has been involved in a financing deal in Canada in the last 5 years can wince at this conversation. Financiers are in the business of buying low and selling high so they’ll point first to the book value of the company which almost always small. Software publishers generally take the opposite view. After all, they probably wouldn’t have started development on the products they’ve created if they hadn’t thought the result would be tremendously valuable to the market. Even if those products haven’t yet been released to the market and haven’t generated any revenue at all, they will perceive them as very valuable.

The truth lies somewhere in between of course. There are a few factors to consider for software and other high-tech manufacturers. Let’s tackle the easy one first; the commercial aspect. The revenue stream itself including existing and repeating clients is obviously key. It’s also not too difficult to identify the marketing expenses associated with a particular product line and most selling organizations have good records of the selling costs thanks to commission and sales bonus structures. These costs can help identify how much effort and money would be required to duplicate the results of the firm, a good indication of the value of what is being purchased.

Brand recognition may be important also. There are several accepted method of valuating a brand name but all of them involve some subjectivity. Trademarks is one of the areas to look at here, particularly registered trademarks and website addresses.

Next, however, is what should be the easiest and is often the toughest aspect of valuating technical efforts: the costs. First of all, there is the direct effort that was required to produce the product or products in question. This is often a labour oriented conversation but it might become critical down the line if you can’t identify what the relative labour involved in producing and selling a product was if it becomes very successful and a key element in a company purchase. Bear in mind that if you are on version 5, then the efforts to create versions 1 through 4 are relevant also (Taking into account some appreciation as you would do with any asset). A project-based corporate timesheet system may allow you to track these efforts task-by-task.

The R&D tax claim that many Canadian companies file each year is another method of quantifying the value of the research undertaken as part of any commercial effort but this also will require a task-by-task accounting.

Next, the value of the knowledge itself is critical to the valuation. Are there unique algorithms or methods of implementing the product line that can’t be replicated elsewhere? Valuating this is difficult but one way of doing it would be to estimate how much effort it would take a competitor to duplicate the efforts. Patents may be one of the methods of quantifying uniqueness here.

When you start thinking like this, you start looking at your business in a whole new light and I think that’s the point the FASB wanted to get across. You start looking at the knowledge base you’ve built up as though it’s an asset. Are you protecting that asset as well as, say the furniture in your office? Your furniture is probably insured and may even be protected behind an alarm system. Is it the same for your much more valuable knowledge? Are you backing up critical information off-site? (Not just your source code.) Are your employment agreements ensuring that employees cannot redistribute the critical information from that knowledge base to competitors upon their departure? Are you copyrighting your software code or applying for patents for firmware or hardware innovation?

The FASB is an American institution but thinking of the value of the knowledge in your own organization is universal.

From small projects, large projects grow

huge-tree-2You’ve heard the expression “From little acorns big trees grow.”  The same can be said for projects.  There’s something compelling about the big project, the huge project, the significant project. There must be because almost everywhere I go, people take little projects and try to make them bigger.

It might start innocently enough, the project team brainstorms in the early planning stages and a mind-mapping exercise takes the little project and gives it branches from the main idea and the branches grow twigs and the twigs grow leaves and before you know it, it’s blocking out the sun!

Or, perhaps a consultant might have thrown in his two cents. “We should do something magnificent,” he might say (thinking of how many of his colleagues might be able to join him on the job.) “It’ll be a project that endures through the ages.”

Whatever the cause, before you know it the initial idea has now become a humongous idea and the size of the project carries its own risks. The more complex a project is, the more likely it is to fail. We talk a lot in here about being effective, about using our systems to make us as productive as possible, about using resources expeditiously. I’m pontificating all the time about how we can handle those big projects and tackle even bigger ones at the same time if only we could use our project systems most effectively. If we think of the 3 sides of the project management triangle: Scope, Time and Resources, we’re always talking about fixing the Time or Resource sides. The one we almost never talk about reducing is “Scope”.

So today: a few thoughts from the chain gain on turning big rocks into little rocks. Yes, that’s right, making a smaller project out of a larger project.

Let’s pause a moment. Doesn’t that go against the grain? Aren’t you having one of those uncomfortable nail-on-chalkboard kind of moments right this second? It’s a cultural thing. AS project managers, we embrace complexity. We take it as a challenge. After all, if the project is too simple, they won’t need us. No one wants to put on our resume, “Managed numerous really small, really simple, low-risk projects”. No! What we want is “Managed schedule for the space station” or “Managed 20 year project for Cure for Cancer”. We are pulled to the complex project and that may be part of the problem. It seems like heresy to even promote a simpler project but let’s suspend our disbelief for a moment and see if it makes sense.

First of all, almost every project can be broken into pieces. In almost every project there is a kernel of an idea; a base functionality or a core construction. Even in large complex projects, breaking the project into manageable pieces makes sense.  No one wants a schedule with 100,000 tasks. But 20 projects with 5,000 each might just be manageable.

Even when you’re committed to a set list of functionality, releasing it in phases still makes sense. Yes, I know there are times when that’s just not possible. While it may be true, it’s the exception, rather than the rule.

“But wait,” you say, “if we do the whole project together, we’ll maintain the overall vision of the project.”

Yes, that’s also true but that benefit comes with a host of risks. Let’s take a look at some of the advantages and disadvantages of making projects smaller:

Advantages

On the good side, a smaller project almost always has less risk. It’s smaller, easier to understand, the finish line is that much closer than it would be in a smaller project and the whole team can drive towards the finish almost from the beginning.

A smaller project is also easier to schedule resources for. The key personnel in any organization are going to be easier to lock up for a short period for a smaller project than they are for a longer more complex project. Key resources (we’ve talked about them in here before) can’t be locked up in a single project for long. They’re key for a reason. So, the longer and more complex the project is, the more likely that you’ll only get partial attention from those kinds of folks. The shorter the project is, the more likely the chance that you can get key people dedicated to it.

A smaller project gives back some return on investment sooner. It’s true that the return will be lower than what you were hoping for from the entire vision of the bigger project, but it’s return coming in now rather than later and regardless of how you’re measuring that return, it’s always good to have some value coming back into the organization.

Finally a smaller project makes for faster successes and shorter, faster successes breed their own energy. The longer and more complex a project is, the more likely it is to suck the energy right out of a team.

Disadvantages

Ok, it’s not all grins and giggles. There are a few down sides to making your project smaller. First of all, there’s a significant risk that the initial vision for the project will never be realized. Often what happens is the 80/20 rule takes hold with a vengeance. The first 80% of the value gets delivered with 20% of the effort. The last 20% of the value takes another 80% of effort. So the problem becomes keeping the attention of management or the client when you’ve gotten the first 20% done. By the same token, going for funding piecemeal makes a significant risk that you’ll get funding for the early parts of the project but not the later parts.

Next, there’s a chance that we lose cohesion from the original vision. With the project now broken up into smaller pieces, it’s possible that the original idea will be lost as we deal with each tree rather than the forest.

If we think of taking an initial vision and breaking it into distinct smaller projects, one of the risks is that it ultimately costs more. While I think this is possible, you’ve got to temper the chance of this happening with the benefit of getting return on investment along the way with the completion of each smaller project that’s part of the whole.

So how do I do it?

Ok, so there are some drawbacks and some advantages to making smaller projects out of your larger projects. If you’ve decided you like the idea how do you do it?

Start with identifying the kernel of the idea within the larger project. If you can identify some kernel of functionality or core principles see if those can be crafted into a base project from which other parts of the project could evolve.

If you’re looking at technology, then phasing in functionality over time can be another way to articulate the various pieces of a larger vision.

We look at projects to see whether we can divide up their functionality by geography, functionality, people or source of funding. If you stop and look at the whole, there’s almost always a way to break it into pieces. Then you’ve got to decide if you absolutely need to maintain the original vision which you can do in a separate piece on its own. Call it the integration or supra-project if you like.

We talk about this concept in project management all the time when we train new project managers. “Break the project into smaller and smaller components until you’ve got something you can manage,” we tell people. Keep this in mind as you face the temptation of larger and larger projects.

The Electric PMO

7252413Awhile back I had the great pleasure of sitting in on a round-table discussion aother project managers and doing peer-to-peer learning is by far my favourite. The topics in this case were on placards at each table and you could just select the subject that was of interest and sit in for a half-hour discussion. “A successful Project Management Office (PMO)” caught my attention and I sat in on both sessions to listen in.

I was not at all surprised to find several varied opinions about how to make a PMO successful but what was most interesting was the wide range of ideas over what constitutes a PMO and what its purpose should be. If you’ve read my column before you know that my focus in the industry is on project management systems but imagine the challenge for someone in my area if it is that difficult even to define a PMO. Let’s take a look at a couple of different perspectives of what a PMO could be:

The Owner
It’s the rarest of all PMOs. In this scenario, the Project Management Office has ultimate authority over every project manager. The project managers report directly to the PMO. We see this most often in a mega project environment where the entire organization has been created in fact, to accomplish a particular project. It can also happen in Defense and Aerospace projects where the government has imposed project management standards which define how the organization must manage. In this environment we’re more likely to find a small centralized project management office staffed by highly skilled full time project scheduler and project cost analyst personnel.

The tools that are chosen for this situation are heavy on the analytics and light on user-friendliness. Compliance and collaboration are not the first concerns here. What’s more important is that we can do strong forecasting, strong project accounting, that we’re able to have sufficient flexibility to integrate directly to the organization’s ERP and corporate reporting systems. We focus more here on government or contract compliance so we’re more likely to find things like requirements for Monte Carlo risk analysis and Earned-Value standards for cost analysis.

The Coach
(No, not the couch – that’s where PMO staff go after a long day!). Perhaps the most common PMO role today is that of mentor or coach. They’re not there to impose their authority on a project or on the project manager but rather to be there to guide the Project Manager, to offer assistance if needed, to provide tools and resources in order to help the project get out of trouble.

In this case, the PMO is more likely to be a small, highly skilled group and extremely unlikely to be hosting a strong centralized enterprise project management or enterprise portfolio management system. They’re more likely to offer tools that each individual project manager can use and to facilitate training exercises and the delivery of easy-to-implement templates. There’s not much room here to police the projects under the coach so the role is supportive rather than prescriptive.

If it’s all about supporting others, the ability to disseminate information is more important than our ability to collect it. So, we look for tools that are strong on document management, strong on communications and light on centralized analysis.

The Scout
Many PMO’s are set up like the Defense Early Warning (DEW) System of cold-war fame. The purpose of the office is to identify potential problems within projects and to report back on this to management. Scout PMOs don’t have much authority but often they are much more than reporters. After all, if they can identify the problems early on, why not try to tackle them up front. It’s not unusual to find a desire for an enterprise project management system here but deploying one can be a challenge. The Scout PMO is often empowered from the highest levels of management and that’s a good thing if you’re trying to deploy an EPM system. However, they’re often viewed with suspicion by the project managers themselves and that’s an awful thing if you’re trying to get the cooperation you need to get an EPM system used by everyone.

Systems for a Scout PMO will be strong on data collection, strong on reporting and a little lighter on heavy analysis. Assembling information from numerous disparate sources into a single view for management is almost impossible so the Scout PMO will lobby heavily for data collection and tool standards as well as some semblance of standards for projects such as coding for stage gating phases and project durations.

The Facilitator
While it’s not yet the most numerous, certainly one of the most desired types of PMOs anywhere is that of the Facilitator. This kind of PMO doesn’t have authority over the rest of the project managers yet it doesn’t have a passive role either. The PMO’s role is to facilitate the execution of the projects under its purview. This means that the role includes that of the Coach and the Scout. It’s often said that a facilitator has the toughest role in a negotiation. They are held responsible for the result but carry no authority to generate it and that, indeed, is how it works in this environment also.

The Facilitator PMO will have the backing of senior management but will be a dotted line on the organigram. Without authority, they will resort to cajoling, threatening, inspiring, evangelizing and pleading in order to produce the result and it’s often very successful.

The PMO will be characterized by a small cadre of highly trained and highly charismatic personnel. We’re most likely to find a successful Enterprise Project Management system implemented with this kind of PMO. Communication and collaboration are very significant desirables in this scenario and that is often a key to making an EPM system work. Also, centralized information is essential to the Facilitator being able to identify areas in which project managers, team leads and management must collaborate so getting all project data into one place is going to be an essential part of making the Facilitator PMO successful.

There are other kinds of Project Management Offices so if I’ve not mentioned yours or if yours is a hybrid of the couple I’ve described, don’t fret. The point is that before you head off to choose project management software ideal to your PMO or before you start to implement the project management software you’ve got, it’s worthwhile to think about what role you’re trying to fulfill. None of the definitions I’ve listed are the “best”. They’re all specific to what an organization is trying to accomplish and the particular business challenges they are facing at that time. In fact, it’s not unusual to see the role of a PMO change over time as the organization it serves changes.

Most high end enterprise project management packages these days have so much flexibility that they can be deployed in many different ways. You can focus on so many different aspects of these systems that they can easily support many different PMO scenarios. So, think about your PMO scenario before leaping directly to installation and training of the system you’ve chosen.