Detailed schedules and beautiful Gantt charts might stop the screaming for visibility into your project, but they won’t help you sleep at night. In the back of your head, you’re waiting for the binky to fall out—for the project timeline to slip—and everyone starts crying again. Here’s how to break the habit of leaning on these common IT project management crutches.
Almost 30 years ago, when my wife and I were proud and exhausted new parents, we found that pacifiers would help our newborn twins sleep. This strategy worked for a little while, but when a binky fell out of one of their mouths, they cried. One of us would get up, put it back in place, and enjoy a few more moments of rest until it fell out again. We always say that one of the things we would do differently as parents is to have not used pacifiers. The boys became dependent on them, and they only postponed the inevitable.
Binkies remind me of how IT teams often use detailed timelines and project plans.
In a waterfall environment, project managers establish an ambitious scope. They estimate resources required to deliver the full wish list on a given date. This plan is circulated to executives, who sign off on it, keep a copy, and make further decisions based on it.
The problem with this approach is it’s about as successful as forecasting the weather 90 days in the future. There is a less than 20% chance you will deliver on time, on budget, and on scope. As times goes on, the timeline slips. The team repeatedly falls short of expectations by missing key dates or reducing the scope along the way.
Extended timelines, detailed schedules, charts, and similar pacifier-like devices make IT project stakeholders feel good at first. They are familiar and soothing. But they create a false sense of security. As soon as things start to veer off plan, the crying begins, figuratively speaking. New dates are established, hushing everyone for a while. Then they change again.
A longterm project plan is the binky a PM uses to pacify the management team. This strategy never addresses the underlying need to help the organization reduce its dependency on fully-scoped timelines.
How did we get here?
When waterfall projects were scoped, business partners were trained to ask for everything including the kitchen sink. If it wasn’t in the requirements up front, it wasn’t baked in to the plan. To add anything later was a big deal.
So, stakeholders were encouraged to add any feature they might ever want, and they wanted to see it on a timeline. Otherwise they would surely never get it.
How to break the habit.
It’s time to reset expectations.
In reality, the business can’t get everything it wants. And it can’t even get everything it needs on Day 1. Agile helps us work within this reality and frees us from setting unrealistic expectations in rosy, Gantt chart format.
When transitioning to Agile, one of the hardest changes an organization experiences is the mindset shift away from scope- and date-driven thinking and toward Minimal Viable Products (MVPs) and iterations. Below is a step-by-step guide to wean your team off extended project timelines and fully scoped plans, setting them up for success.
Step 1. Accept that sometimes dates are important.
In an ideal world, you won’t have a target date.
Dates are often set by someone who thinks the best way to spur action is by setting an arbitrary deadline. Sometimes dates are set for compliance-related reasons, commitments made to investors, dependencies with other strategic initiatives, or expectations set with external stakeholders.
The quickest way to alienate date-driven stakeholders is to declare, “Dates are not Agile.” I’ve made this mistake; the response isn’t good. It works against your effort to transform mindsets from timelines to iterations. Don’t begin the conversation by saying the uninformed date is bunk.
Instead, empathize with stakeholders by recognizing the product or project is intended to add business value, resources were dedicated to it, and tradeoffs were made in order to make it happen. Consequently, the leadership team is under pressure to deliver results. Dates are tangible and must be accepted as a starting point for the discussion.
If you can’t change the date, you can change the scope.
Step 2. Limit the number of decisions makers to a critical few.
When scoping the project deliverables, try to restrict the number of people in the room. Only invite a critical few to define the MVP, for example:
- the product owner
- the technical resources who understand architecture and dependencies, and who can estimate overall complexity of features
- (optional) an unbiased facilitator who may not even know the business or technology
Step 3. Create a wish list of major features.
Define all the elements that will make the project or product a success. Listen, document, probe, and gain agreement on the value, dependencies, and constraints. Focus on the outcome, and not on the development process required to achieve it. Produce the list of wants.
Step 4. Move the conversation from wants to needs.
Once your business partners are confident you recognize the importance and scope of the project, carefully shift the conversation from wants to needs. Remember, they are still thinking about the whole enchilada. Encourage them to think about short-term and long-term timeframes. Talk about the difference between needs and wants, and gain agreement on how to categorize each feature. It isn’t easy to reclassify a feature from a need to a want, so politely drill down and keep asking, “Why?”
Step 5. Ask the question: “What do you need on Day 1?”
In the previous step, all the needs were identified. Now discuss which of those needs must be met by a given date. You’re approaching a defined MVP—but don’t commit yet. Begin the process of culling out absolutes and teasing out iterations of the requirements to support adoption, experimentation, compliance, or other business need.
Put all requirements in one of two lists: Day 1 and Not Day 1. (Tip: It’s not necessary to prioritize the entire backlog.)
Step 6. Prioritize features within the MVP.
Now that you have identified your MVP requirements, prioritize them. This allows you to take a second look at what is really needed on Day 1. Those on the bottom of the list are candidates to be removed from consideration.
Step 7. Get a technical perspective.
With a first draft of the MVP defined, your technical team can evaluate it and estimate how long it will take to build. An established scrum team will know its velocity. It’s more challenging for a newer team, but not impossible.
Ask them to develop questions, critical obstacles, potential alternatives, and crazy ideas. Can they meet the Day 1 target date, if there is one set by external factors? By involving the team now, they begin to buy in on the date.
Step 8. Negotiate and iterate.
Bring all the stakeholders together and review the technical team’s evaluation. Discuss if delivering the MVP on the target date is possible. If so, you have a plan. The team may need to refine the scope again, and some parties may need to do more research. Once this is done, reconvene. Steps 6-8 may cycle multiple times.
(The likely, and often preferred, outcome of this step will contain more than just an MVP with a date. There could be multiple iterations leading up to and following the completion of the MVP.)
Step 9. Communicate with caveats.
It’s time to share the scope and date with all stakeholders, but the MVP should not be considered set in stone. It may still be fluid as business and technical unknowns become known. Some items may need to be added, and others removed. All this should be done collaboratively and with the intention of creating the most value for the customer.
Step 10. Get stakeholders comfortable with uncertainty.
Someone will have a pet feature in the backlog and want to know when to expect it. Reassure them that just because it doesn’t have a date assigned to it doesn’t mean it won’t happen. Shift the conversation with the advocate back to the value it will deliver to the client, relative to the value of the other priorities, and invite a healthy debate about sequencing, rather than dates on the calendar.
In short, a detailed project timeline crams all potential features into a nice-looking, well-intentioned, longterm schedule that will only let you down. Break your dependency on this crutch. Toss the binky.
If you’re handed a fixed date, manage expectations by getting laser-focused on scope. Go from “wants” to “needs” to “needs on Day 1” for a realistic MVP that will deliver value and build trust.
Why did we give the binkies to our sons? Sleep and sanity. These are real needs—no different than business value and dates. We tried to take the easy way out, not understanding the long-term impact of the short-term fix. It took us years to wean them off pacifiers. When they were babies, we couldn’t communicate to them in a logical way. Assuming you have a few mature adults in the room, the process above will help stakeholders have confidence in the team’s rational approach to a realistic scope and date, without demanding the empty comfort of a detailed timeline.
