180 View – Interesting perspective but I don’t think it’s possible to have a root cause for project failures. There are as many causes to failure as there are different kinds of people. However encouraging the project team to express their concerns is a very good idea. More than that, I would encourage project managers to seek out the naysayers and ask them for their opinion about the risks, probability, impact and most importantly what should be done about the risks.

The Oxford University researchers examined 1,471 information technology projects, in private and public sectors, comparing budgets and estimated performance benefits with actual costs and results.

They had expected to find IT projects incur large average cost overruns, but they were surprised to see fully one in six projects — nearly 17 per cent — were so mismanaged that they had average cost overruns of 200 per cent, not factoring inflation, and delays of 70 per cent…”

180 View – IT projects usually involve unknowns and when selling or estimating time and budget, assumptions are made. So the solution is to try to reduce the unknowns by clearly defined scope and to expose the assumptions. It sounds simple, but it takes a lot of up front work to get this done properly before making a decision to proceed. As well, project failure should not be based on overruns. Project failure should be based on whether the project objectives are met.

180 View – Even if this article was not written by our associate Lisa Anderson, we would have still commented that she has written a useful article that is quick and easy to read.

1. A decision never gets made or is delayed – By trying to get everyone to agree, stubbornness can kick in and individuals can stall or stop decisions from being made.
2. A weaker solution can be determined – By trying to include something for everyone the best solution can be watered down.

180 View – We agree and would add another reason. Not all stakeholders are qualified to make a decision. They may not see the forest for the trees – in other words they are focused mostly on their own departments rather than the business as whole. They may also not have the intelligence or the experience to make the best decision. But you should seek input from stakeholders as they often have insights that are not known. As well, it leads to buy in as they have been able to influence the decision and their opinion is respected.

• Padding…
• Being overly optimistic…
• Bad requirements…
• Omission…
• Different levels…
• Being put on the spot…
• Forgetting the risk factor…
• Pressure from above…
• Failure to involve the “do-ers”…”

180 View – Estimating is tough and we ask for it all the time from the vendors when assisting our clients in a system selection project. The vendors don’t have enough information when responding to an RFP so they rely on past experience based on similar sized projects and what they think the market will bear or on the budget of the prospect. Later we give the AS-IS business process and invite the short listed vendors to meet with our clients to get a better understanding of scope so they can give a better estimate on the implementation. Unfortunately the vendors often still don’t have enough information to get it right. We suggest that you ask the vendors to break out the project estimate by module and by task. You may find startling differences in their numbers. We also suggest that you ask the vendors to conduct a needs analysis prior to finalizing the deal. One of the objectives of the needs analysis should be a firm quote on the implementation.

180 View – We also agree that clearly defined requirements are critical to the success of any project. Requirements can differ significantly depending on the project. When gathering requirements for a system selection project, it is counter-productive to define every field or every report. However when gathering requirements for a software development project, a lot more detail is required. In a past life, I (Michael Burns) developed detail design specifications for a company called Minicom that at one time was the leading software developer for real estate companies in Canada. Our specifications included an Entity Relation Diagram that showed all the tables, fields and their relationships. We also included specifications for each field, each process and each report. We also provided a prototype of each screen and each report.

• Nearly three quarters (72 percent) of CEOs/COOs and project managers identify the ability to manage projects as critical or absolutely critical to the future growth of the business.
• Despite this, just 11 percent of CEOs/COOs and project managers are very confident of their ability to manage business-critical projects in the most efficient way…

180 View – The article lays the blame on the tools with “Concerns about access to the important information required to run projects efficiently and on time” Better tools will help but a good project manager will overcome limitations in tools. Project managers often start in IT and gradually take on project management positions. They may be good at the technical side but it can be a huge leap to be an effective project manager knowledgeable about business and an effective communicator.

180 View – Lisa has her own company but is also an associate of 180 Systems. I (Michael Burns) was so impressed by her writing that I contacted Lisa and asked whether she would be interested in working with us. Hopefully in the near future, we will have the opportunity to do so.

180 View – The article provides recommended steps for the project, metrics to consider as well as a case study. The information might be of some assistance for organizations planning a business process improvement project. But I think the main point is that project management methodology can and should be applied to business process improvement projects.

180 View – The article also discusses three qualities in an excellent project manager one of them being the ability to synthesize. The author, Lisa Anderson, has certainly demonstrated her synthesizing skills by being able to come up with the three qualities.

“One year ago my company embarked on an enterprise-wide implementation, selecting an ERP system and a suite of software to address our primary business functions. This decision was not made lightly. Lestornia Lighting is a $120 million manufacturer of commercial and industrial lighting fixtures and components (e.g., sockets, lampholders, wiring harnesses, reflectors). We’ve grown incrementally over the past two decades, and our business practices and processes — and the information technology (IT) that supports them — has grown piece by piece as well. I finally concluded that the Frankenstein IT infrastructure we had cobbled together needed to be destroyed. Now I greatly regret my decision…”

Literally from the outset of our enterprise implementation, the scope of functionality, customizations, and departments and personnel engaged in the effort have spread like wildfire. Lestornia expected to be operating with our new systems six months ago; now we cannot get a projected date for when we will hit the switch. The escalation of costs specific to software licensing and the implementation have blown beyond anything I’d ever imagined. And with the infectious spread of applications and department-specific functionality and customization, our training and maintenance costs are doubling by the day.

I swear that every person in the company is working on this system and software implementation in some way or another, and no one is focused on making lighting products or focused on our customers. I am afraid that this project will, quite simply, kill Lestornia before we ever see a dime of return from our investment. How can we subdue the new monster we’ve created?”

180 View – Although the problem is hypothetical, most people have heard of similar nightmares. Our opinion is that the risks of these problems occurring have been significantly reduced, but not eliminated. There are many ways to reduce the risks but the one that seems most relevant in this case is lack of scope and requirements definition prior to the selection of the new system.

1. Scope creep
2. Asking customers what they want
3. Inability to adapt to change
4. Failure to communicate effectively
5. Failure to communicate frequently
6. Unwieldy documents and too much information
7. Hidden project artifacts
8. Ambiguous requirements
9. Failure to measure and assess requirements processes
10. Isolating your requirements

180 View – Although the article was written for getting requirements for software development, it also applies to getting requirements for a software selection project. The key difference between requirements definition in software development and software selection is in the level of detail.

One would not expect “asking customers what they want” to be a trap. The article claims that “customers tend to talk about features, not what they truly need. The truth is that people often don’t know what they want.” The article says the solution lies in asking customers why they need a particular solution. I agree with the problem but not the solution. It would be better to ask the customer to describe their existing business process and its problems. In this way, the customer exposes the strengths and weaknesses of the existing system, and the business analyst can suggest alternative ways to solve the problems. The business analyst should know what is possible in software development and what is possible in existing systems but also needs to understand the business impact of a particular problem. There is no point in creating or implementing an expensive solution to a problem that causes a few minutes to be wasted a week for one person even though the customer finds it annoying.

The article’s list is

1. Inspires a Shared Vision
2. A Good Communicator
3. Integrity
4. Enthusiasm
5. Empathy
6. Competence
7. Ability to Delegate Tasks
8. Cool Under Pressure
9. Team-Building Skills
10. Problem Solving Skills

and you will find a description of the qualities in the article.

180 View – I also get the same question from our clients as to what makes a good project manager. But our answer is not the same as the article. Perhaps the reason for this is that our clients are usually asking about project managers for an ERP implementation. My advice published in October 2008 for CAmagazine was “a good project manager listens well, sees the big picture, is also detail-oriented and can communicate effectively. The project manager is highly motivated to succeed and enjoys challenges. Finally, the project manager has the backing of senior management and the respect of his or her peers. For an ERP project, the project manager should also know the business, and the scope of an ERP project typically includes at least financials and operations. It’s not easy to find one person who combines the right attitude and aptitude with business knowledge of both financials and operations. And to make matters even worse, the project manager will be very busy with the ERP project and unable to work on other tasks. I recommend picking the person who comes closest to meeting all the attributes, which actually leads to one more characteristic – the ability to delegate. Take your time on this decision, as the project manager can make a big difference in the success of the ERP project.”

It is very tough to find a project manager who not only has the business experience, but also skills, aptitude and experience in project management. My advice is that it is more important for the project manager or project lead to have the right aptitude and knowledge of business. Pure project management skills can be outsourced.