3 Signs of a Run Away Project
Published November 27, 2013 | Categories: Web Development
Tyson Brands sits down to his desk, second cup of coffee in hand, and begins checking his emails, like he does every morning. He notices one email flagged as important. The subject line just reads "Update!" Tyson doesn't need to read the email to know what it's about. The client is asking for yet another update on their big project.
As Tyson stares at the email, he imagines the client reacting to the bad news he has to deliver. The truth is, the project is behind schedule again, and it looks like he's going to miss another in a long line of failed deadlines. Tyson leans back in his chair and stares at the ceiling. He never neglected the project, and he spent a lot of time with the client fleshing out the requirements at the beginning. It should have been fairly straightforward, but here he was three months past the launch date and so far beyond the budget Tyson was sure his company wasn't even making money at this point.
If this scenario seems at all familiar, then you know what it's like to be involved with a runaway project. Nobody wants to be a part of them. Things like "deadline" and "budget" lose all meaning. Like the name suggests, a runaway project has no end in sight. The challenge is to know when a project is on its way to being out of control and addressing it sooner rather than later. Easier said than done in many cases, but the best defense is a good offense. The first thing to do is to establish a list of criteria that can alert you to potential problems. Here are a few ways you can tell if you've got a runaway project on your hands:
Bad flow of information/vague requirements: knowledge does not flow linearly. Each new person you add to your project complicates the flow of information. As PM, you need to make sure everyone is on the same page and is lock-step with what the client wants. Most projects are too complex for you to be available to make all the decisions, and you need to rely on your team to make functional choices surrounding their particular expertise. If not everyone is on the same page, then you'll spend more time going back and correcting decisions others have made. How can you tell if you have a bad flow of information? Ask each person working on it individually to describe the project in terms of what it's trying to accomplish and how their actions are helping the project succeed. If you get wildly different answers, you may have a problem.
Changing scope: assuming you have clear requirements, scope creep shouldn't be a problem right? Wrong! Every project has to make some changes along the way. Sometimes there are valid reasons for doing so, such as having to adapt to a changing business environment. Other times, you may just be dealing with too many decision makers with unique visions of what the project should be. Document every single change that comes in along with the impact it will have on the budget and the deadline. The goal is to create a clear trail of decisions to explain any differences between the initial scope and the final product. If you see a steady accumulation of hours needed for these out of scope changes, you might have a runaway project on your hands.
Low client buy-in: nothing is more frustrating when you get the feeling that a project is a higher priority to you than it is to the client. Nevertheless, you're still being held responsible for moving the project along even when you aren't getting the feedback you need. Remember that your client most likely has a clear vision as to what they are expecting (even if they can't describe it), and it will rarely be the same as yours. When you plan out your project, make sure you plan for iterative milestones and approval periods. Establish an expectation upfront of turnaround for feedback and approvals, and gently remind the client when their decisions will hold up the project.
Looking back on his project, Tyson realized that the client had changed the goals twice and had near 15 change requests. On top of that, there would be long gaps between when a deliverable was turned over and any response from the client. In fact, Tyson was usually the one that prodded the response. Tyson was more than certain he had a runaway project, now all he had to do was figure out how to fix it...
Recent Posts
