Project Management is not rocket science
There is no worse person to be than the project manager at the end of a failed project. As an IT project manager, I have experienced that feeling and I can tell you it’s not nice. IT projects are particularly difficult to manage. In fact there really aren’t any IT projects, just projects that have elements of IT in them.
The trouble with these projects is that often you are doing something that hasn’t been done before, is unproven or cutting edge. Customers expect a good result not excuses, even though these projects are frequently a journey into the unknown. If we take the construction industry, building a new bridge for instance, we have been building bridges for hundreds of years and know how to do it. We understand how things are going to happen, in what order and the expected result. This is rarely the case with IT projects.
Avoiding the common pitfalls of IT project management is not rocket science, it is simply a case of taking some sensible measures. Identified here are five killer mistakes of project management:
Who Owns the Project?
The Mistake:
The nature of projects is change and change often encounters resistance. People don’t like change so they need to know it is necessary and what benefits it will bring. In order for a project to deliver change it needs the backing of senior management. Without it the project will proceed very slowly. The sponsor (senior management) is the person that drives the change forward and the project is the mechanism for change. A project without support from senior management will struggle.
The Solution:
Make sure you have the top down backing from senior management. There must be direct communication from the sponsor to the stakeholders. The message must be, “we are serious, this thing is going to happen so you are either with us or you are not” and beware those that are not.
Be careful as project manager to make sure the sponsor does not take the project over and become the de-facto project manager.
Getting Users Involved
The Mistake:
Lack of user input and involvement is the recipe for a bad project. This can either be because of the “we know what you want” mentality from the IT department or lack of interest from the customer. Either way it must be avoided.
The Solution:
The IT department must take time to understand the customers requirements before proposing any technical solution. Often IT is blinded by the latest, newest thing available and try to shoehorn the requirements into it. On the other hand, customers must devote the time and effort necessary to ensure a successful project by interacting with the IT department and making sure all requirements have been fully defined. Ensure you have spoken to all stakeholders to gathered their requirements and that they continue to work with you for the duration of the project.
Stopping Scope Creep
The Mistake:
Scope creep is the cause of more project failures than anything else. Not knowing exactly what a project is aiming to deliver or setting off in a fit of enthusiasm but little else, is a recipe for failure.
The Solution:
Ensure that the business case, requirements and scope are clearly defined and documented. Make sure the stakeholders understand them and sign them off. Stick rigidly to the scope and if changes are required then put them through a change management process where they are documented, justified and then agreed.
Managing Expectations
The Mistake:
Often there is an expectation that IT is like a magic wand you wave and suddenly a miracle occurs. During a technology project expectations can inflate to a ridiculous degree. It is the role of the project manager to manage expectations to a sensible level.
The Solution:
One way to avoid this is to break a project into smaller pieces or phases. I equate this to a sausage machine, where you feed in the raw material at one end and out it comes as small, perfectly formed, packages or sausages at the other end. The same can happen with IT projects where you take small packages of requirements and push them through the machine, producing several deliverables over the life of a project. This way you manage expectations by making frequent deliveries to demonstrate what the technology can really deliver. This approach ensures the project delivers to the customers expectations by giving them early visibility of what you are building.
Understanding the Lingo
The Mistake:
Have you ever stood next to a group of IT professionals and wondered what on earth they were talking about. It is like a whole new language and to non-IT people it often is. The pitfall comes when the customer and IT think they are talking the same language when in fact they are not. This leads to a problem when the IT department delivers what they understood the customer wanted and it turns out to be something different.
The Solution:
Communication problems are the hardest to resolve as often it is only looking back that the problem is identified. Regular communication and a close working relationship with the customer will help. What you really need is a person with a foot in both camps. Someone who understands the business and the IT equally well. If you can identify this person make sure you keep hold of them, they are hugely valuable. If you are unable to find this person, the next best option is to have two people, one from the business and one from IT. By working closely together and sharing information they can minimise any communication problems.
Finally
In 1995 The Standish Group surveyed IT executive managers for their opinions about why projects succeed. The three major reasons given that a project will succeed are user involvement, executive management support, and a clear statement of requirements. Concentrating on these three aspects alone will give your project a good chance of success.
Don’t become the victim of a failed project, put measures in place that will ensure your success. After all it’s not rocket science!
Read more about IT Project Management
No related posts.
{ 6 comments… read them below or add one }
Duncan,
Can’t you start with a framework for solving these issues:
1. Who owns the project – the project charter should say this. The PM needs to make sure this person knows it and acts accordingly
2. Getting users involved – a RAM / RACI chart is the starting point. Named members, their RACI items. Make this a BIG VISIBLE CHART so they don’t forget their Accountability. The PM’s role is to not let them forget.
3. Managing Expctations – we’ve swtich to Capabilties Based Planning and the support Deliverables Based Planning implementation. With the Owner and RACI, a business capability describes the operatioal aspects of the system when that capability becomes available. This does not “cure” the disappointment problem, but it goes a long way to having the users understand the disappointment before it arrives.
4. Communications – we usually have a “political officer” on ERP projects. Her job (her seems to work better at this) is to keep everyone “in the loop.”
A side bar question, do you find Prince2 to be a better fit for IT than PMBOK based processes?
Duncan,
Can’t you start with a framework for solving these issues:
1. Who owns the project – the project charter should say this. The PM needs to make sure this person knows it and acts accordingly
2. Getting users involved – a RAM / RACI chart is the starting point. Named members, their RACI items. Make this a BIG VISIBLE CHART so they don’t forget their Accountability. The PM’s role is to not let them forget.
3. Managing Expctations – we’ve swtich to Capabilties Based Planning and the support Deliverables Based Planning implementation. With the Owner and RACI, a business capability describes the operatioal aspects of the system when that capability becomes available. This does not “cure” the disappointment problem, but it goes a long way to having the users understand the disappointment before it arrives.
4. Communications – we usually have a “political officer” on ERP projects. Her job (her seems to work better at this) is to keep everyone “in the loop.”
A side bar question, do you find Prince2 to be a better fit for IT than PMBOK based processes?
Duncan –
The “Five Killer” mistakes that you identify are very real problems whether you are building a bridge or a piece of software. And (as Glen notes) there are good solutions that have been well known for years. RACI charts have been in use since at least the mid 1980s, and the generic form of the RACI, the Linear Responsibility Chart, appears to go back to at least the mid-1960s.
Why can’t IT learn from other project management disciplines? One key reason is that IT continues to position itself as “different” by using inaccurate analogies. Comparing building a bridge (a single phase of an asset development project) to the full range of problems with software development is grossly misleading.
We have designed and built many bridges over time, but today’s cable-stayed suspension bridges have little in common with early wooden bridges. Just like software, bridges may be simplex or complex, reasonably independent or part of a tightly coupled system. Bridge building is subject to error (Google “building disasters” and you get 12,800,000 hits; “software disasters” produces only 8,900,000 hits).
Maybe IT would fare a little better if we spent as much time trying to learn from others as we spend explaining why others have nothing to teach us.
Duncan
Duncan –
The “Five Killer” mistakes that you identify are very real problems whether you are building a bridge or a piece of software. And (as Glen notes) there are good solutions that have been well known for years. RACI charts have been in use since at least the mid 1980s, and the generic form of the RACI, the Linear Responsibility Chart, appears to go back to at least the mid-1960s.
Why can’t IT learn from other project management disciplines? One key reason is that IT continues to position itself as “different” by using inaccurate analogies. Comparing building a bridge (a single phase of an asset development project) to the full range of problems with software development is grossly misleading.
We have designed and built many bridges over time, but today’s cable-stayed suspension bridges have little in common with early wooden bridges. Just like software, bridges may be simplex or complex, reasonably independent or part of a tightly coupled system. Bridge building is subject to error (Google “building disasters” and you get 12,800,000 hits; “software disasters” produces only 8,900,000 hits).
Maybe IT would fare a little better if we spent as much time trying to learn from others as we spend explaining why others have nothing to teach us.
Duncan
While I agree with both Glen and Bill on this, let me interject another aspect that is rarely considered or discussed.
As an end user of software, I often don’t know exactly what I want. Worse yet, I probably don’t even know what is available for me to choose from. So part of the challenge before the IT project manager is to help educate your client as to what is available that will meet my business needs.
Bringing this back to Bill’s comment, in bridge design (and architecture in general) there is often competition that determines first what the end product is going to look like. Once the client has chosen what the end product is going to look like, THEN it becomes up to the Architect and Engineer to make the real thing look like the rendering. Maybe IT should look more closely at how beautiful bridges or buildings are created (end to end), learning and adapting from this model, which has been around for literally thousands of years……
BR,
Dr. PDG, Jakarta
http://www.getpmcertified.com
While I agree with both Glen and Bill on this, let me interject another aspect that is rarely considered or discussed.
As an end user of software, I often don’t know exactly what I want. Worse yet, I probably don’t even know what is available for me to choose from. So part of the challenge before the IT project manager is to help educate your client as to what is available that will meet my business needs.
Bringing this back to Bill’s comment, in bridge design (and architecture in general) there is often competition that determines first what the end product is going to look like. Once the client has chosen what the end product is going to look like, THEN it becomes up to the Architect and Engineer to make the real thing look like the rendering. Maybe IT should look more closely at how beautiful bridges or buildings are created (end to end), learning and adapting from this model, which has been around for literally thousands of years……
BR,
Dr. PDG, Jakarta
http://www.getpmcertified.com