IT Project Management | By Duncan Haughey | minute read
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 you are often doing something that has never been done, is unproven, or is cutting edge. Customers expect a good result, not excuses—even though these projects are often a journey into the unknown. For example, let's take the construction industry and the building of a new bridge. We have built bridges for thousands of years and know how to do it. We understand how things are going to happen, in what order, and the expected result. Unfortunately, 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. Here are five killer mistakes of project management:
Who Owns the Project?
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 this support, the project will proceed very slowly. The sponsor (senior management) is the person who drives the change forward, and the projects are the mechanism for change. A project without support from senior management will struggle and may not be completed.
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 is going to happen, so you are either with us or you are not," and beware those who are not.
Be careful as the project manager to make sure that the sponsor does not take the project over and become the de facto project manager.
Getting Users Involved
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 from the customer's lack of interest. Either way, this lack of input must be avoided.
The IT department must take time to understand the customer's requirements before proposing any technical solution. Often IT is blinded by the latest, newest technology available and will try to shoehorn the requirements into it. On the other hand, customers must devote the necessary time and effort to ensure a project's success by interacting with the IT department and making sure all requirements have been thoroughly defined. Make sure you have spoken to all stakeholders to gather their requirements, and ensure they continue to work with you for the duration of the project.
Stopping Scope Creep
Scope creep is the cause of more project failures than anything else. This occurs when a poorly defined project experiences unexpected changes or unplanned growth. Not knowing what a project is aiming to deliver and starting in a fit of enthusiasm, but little else, is a recipe for failure.
Make sure that the business case, requirements, and scope are clearly defined and documented at the beginning of the project. Make sure the stakeholders understand them and sign off on them. Stick to the agreed upon scope, and if changes are required, then put them through a change management process where they are documented, justified, and then agreed upon.
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 become inflated to a ridiculous degree. It is the role of the project manager to manage expectations to a sensible level.
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 it emerges as small, perfectly formed 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 showing what the technology can realistically deliver. This approach ensures that the project delivers to the customers' expectations by giving them early visibility of what you are building.
Understanding the Lingo
Have you ever stood next to a group of IT professionals and wondered what on earth they were talking about? It is like a foreign language, and to non-IT people it often is. The pitfall comes when the customer and IT think they are speaking 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 entirely different.
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 find this person, make sure you keep hold of them, as they are hugely valuable. If you are unable to find someone like this, 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.
In 1995, The Standish Group surveyed IT executive managers for their opinions about why some projects succeed and others don't. They said the three major influences on project success were 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. Instead, put measures in place that will ensure your project's success. After all, it's not rocket science!