According to the 2009 Standish Chaos Report, 68% of IT projects fail, miss the deadline, are over budget, and/or missing key elements. New Bamboo reports that at least 30% of all website projects fall victim to the same issues. Even the most seasoned development teams and project managers experience project setbacks.
From a Project Manager’s point-of-view, what can be done to combat these pitfalls and help your team deliver better projects on time and on budget? In this post, I’ll cover some of the common causes of interactive project setbacks as well as how to avoid them. My findings stem from my own experience as a project manager (PM), as well as anecdotes compiled from other colleagues’ experiences.
7 Common Causes of Project Setbacks
- Lack of Information – from the client and from you
- Multiple Decision Makers
- Scope Creep
- Loss of Feedback for Requirements
- An Undocumented Process
- Project is Rushed to the Final Build
- Use of Incompatible Technologies
How to Avoid Project Setbacks
As a project manager, you should know what’s going on with your project at all times: where it is, how each stage affects it, and how to mitigate any foreseeable risks before they happen. At the same time you must also manage relationships with your client and your internal team. (Note: In some companies, the Account Manager and Project Manager are two separate roles, in which case, you should learn to work together and communicate often to collectively avoid these problems.)
Lack of Information
Many clients you will work with are unaware of how much requirements analysis and work is involved in the process of creating websites and web applications. As the PM, part of your job is to help educate the client on how much information you need from them throughout the process, how last-minute decisions or changes affect the budget and timeline, and to understand his role in the process.
When a project begins, you will need to gather as much information as you can about your new client/project. Sit down with the salesperson that sold the project to find out how the process went and if the salesperson promised any features or functionality not in a “typical” project.
Next, sit down with the client and introduce him to your process and needs. This can also be done through a conference call. I’ve also sent out an orientation survey in advance to learn more about the client, the problem he wants to solve, project goals, the audience, future plans, etc. Find out what he expects of you and tell him what you expect from him during the process, like how often and through what methods he wants to be contacted.
Multiple Decision Makers
Unless you are working with a small company, it is not often that you get to work directly with the head decision maker (DM). Ask who the main DM is and what role your contact plays. A former colleague of mine once worked with a client that said he was the one to be working with him on the website project. After the entire website was completed and ready for delivery, the client showed it to the real DMs and they hated it. Needless to say, the blame fell on our company to salvage the relationship and their budget was blown out of the water for re-work. My colleague’s contact was the liaison to the real DMs, but failed to inform the PM of his role. The PM also failed to ask.
Another scenario of multiple decision makers is when your contact is working with a committee of DMs. Be sure your client contact understands he is to facilitate and manage this committee so you are not bombarded with requests from multiple people that all want different things. They should vote by consensus or have one overriding DM.
Scope Creep
Scope (or feature) creep happens with most projects. Some teams prepare for a little scope creep by building in budget and timeline buffers, but you should minimize scope creep as much as possible. Communication, as with any of these setbacks, is the most important aspect to avoiding scope creep.
If a client asks for an unplanned feature, ask him why he wants to incorporate it. Uncovering the motivation for a request will help you target the real issue. If it’s an extraneous request, simply discuss the (lack of) ROI that it involves and that it doesn’t address the target goal. If it’s a reasonable request and a benefit to the project, inform the client you need to speak with the development team about creating a new use case. You also need to learn how long this new feature would take and that you will contact the client with an estimate since it is outside the original scope.
Loss of Feedback for Requirements
In some way or another, it has happened to me and my colleagues: losing an email with a client request or answer or forgetting to write down important information in the project documentation after a phone call.
When you misplace or forget information important to a project, the client feels unimportant. If it’s a question that needed to be answered and you forgot the answer, you have to call the client back to get that answer. It could also be a request that you missed entirely and the client notices it is missing in the prototype or the final product, so your team has to make adjustments after the fact.
You should have a single location to post client or other stakeholder feedback regarding a project (ProtoShare is a good tool for this). This way, the information is immediately shared with stakeholders and reflected in the requirements documentation. Stakeholders input their feedback directly into the application so you cannot lose it. You can also directly type in feedback while on the phone with the client, so he can verify you have captured his feedback accurately.
An Undocumented Process
If your team does not follow the same process for each project you undertake, you will miss information that is important to the successful completion of the project. I find it helpful to create a checklist for each step in my company’s development process to ensure that no steps are skipped.
This checklist may physically follow the project from one department to another or be tracked in your PM software. Be sure task owners mark off their items when completed and that they don’t try to cut corners. Good organizational skills are very helpful to making sure you can manage multiple projects successfully.
If you currently do not have a process documented for creating websites or applications, sit down with your team and create one.
Project is Rushed to Final Build
An anxious client, tight deadline, and not following a process (as listed above) can all contribute to a project being rushed to final build before it is ready. Be sure to set expectations with your client, understand all the elements the project is to address, and share this information with your client.
Also, stepping through your documented process is important; that’s why you have a process. For many development teams, these steps tend to include Research, Project Objectives, Personas & Use Cases, Requirements, Site Map, Sketch, Wireframe, Design, Prototype, Test, and Build. The client may not be involved in each step, but he should know why you conduct each step thoroughly. If any one is missed or rushed, then the project will be off target and require expensive re-work.
Use of Incompatible Technologies
This issue is related to Lack of Information. You will need to learn who the client’s end users are and what systems or technologies they use so you can ensure what your team creates will work on their systems. You don’t want your team to use coding techniques that don’t render well in browsers used by the client’s audience.
There’s also nothing worse than writing an application in a way that does not integrate with a key system the client uses at his company. Ask him what systems they use and if they plan on changing systems in the near future.
In Summary
There are many reasons why website and application projects fail. However, with the right planning, good processes, good tools, and constant, open communication, you can effectively manage a project to its completion and make your clients happy.
Here are some other resources you may find helpful: