Few people enjoy change; for many of us, it’s a necessary evil. The problem with change in the project management world is that it can cause confusion and uncertainty – especially when it’s a critical change. After all, change can threaten the future of your startup, or business, or one of your employee’s jobs.
Recently, I was thinking back on a construction project from long ago. While construction projects can be just as stressful, project updates and deliverables are easier to manage when you have a final set of blueprints to work from. All of the details and outstanding questions are laid out in front of you and the final outcome is clear.
In business projects, we don’t have that set of blueprints. In technology projects, we may, if we are lucky, have a requirements document, but frequently the requirements are not well defined. Where is the documentation that tells the team, management, or the client what is meant by all of the activity names or descriptions?
This is where project confusion happens – when there is no clarity on requirements, goals, and deliverables. It’s as if the team is stumbling around in the dark trying to find the light at the end of the tunnel. Most of us live in a world of limited resources, and so, we need to make them count – we don’t have time to stumble around in the dark until we get it right. We simply can’t afford to spend months and millions on ventures that aren’t going to help.
The word deliverable is tossed around a lot in the project world, but in my experience few people understand what it really is, how to use them effectively, or why a few well-defined deliverables can save your project.
If you have no understanding of what is wanted by the deliverable description, how will you know how to price the contract or estimate the time? And how will you know how to do it when the time comes? And yet, there are times, when you know you will need an activity done but you won’t know what is involved until later in the process.
Let’s take the example of a project to create an advertising spot for the Super Bowl. One of your activities may be to document your set design and costume details. Until you know more about the spot, how can you possibly know anything about the set design and costume details? Sometimes, you simply have to put in a placeholder.
What happens when you get closer to the date at which point an activity is to be implemented and you are still struggling to get clarity? Is there a strategy that will help you understand the best path forward? This happens so often in startups, where project confusion seems like the new norm. What do you do when you don’t know what to do? Here are some strategies to help reign your team in, get your project back on track and flick the light switch back on.
Understand the endgame for the project you are on.
It’s often necessary to break projects down into phases and treat them as separate projects. It’s just too hard to see that far into the future. In looking at the phase that you are in, where would you like to be at the end?
Analyze your accomplishments and the remaining work gaps.
It helps to review what has actually been done and what remains. What does it take to reach the endgame that you have identified? Then, compare that work against the project budget.
Understand your resource constraints.
As you ask yourself what kind of work you need done to meet the needs of Activity X, Y or Z, consider who will do the work, how much time they have to get it done, and how much sense it makes to spend on the activity at this point.
Sometimes you have activities that involve the creation of documents. There are big differences in what it takes to create a rough draft of a word document with some bullets that will make people think, and what it takes to create a polished document that is ready for publishing.
Start small when you are unsure.
If you really don’t know what the next steps should be, and you’ve tried the first three suggestions, start small. Pick one small activity, get it done, and then circle back with the client, or your management to see how that accomplishment changes the landscape.
Define the quality needed.
Once you have identified the quality, ask yourself who will approve the deliverable. If the activity is to produce an interim document that will be used by someone else to create subsequent documents, it may not make sense for the document to go through all of the RACI team. Define the deliverable well enough to understand what the subject is, who the target market is,
Designate who will approve the deliverable.
Sometimes, when I consult with businesses, they are good about creating RACI’s, a document that is also known as a responsibility matrix. I talked about them in this blog. It’s become somewhat of a standard, particularly in government projects. But I often see the RACI’s organized by topics or work streams, rather than a deliverable by deliverable understanding of who is going to approve what.
Not all deliverables are equal. Some of the documents that you create will be rough drafts that are inputs to subsequent documents. Other documents will be important and final documents that need approval by people at the highest levels.
In a world of rapid change, it is easy for project confusion to rear its ugly head. Try these suggestions to rescue your team, and if that doesn’t help, give me a call.