Prioritize Your Project Timeline with Two Simple Lists
Your stakeholder wants the system perfect on day 1.
He wants full critical functionality, along with lots of bells and whistles on top.
The result: you’re forced to schedule your project timeline with unrealistic deadlines and shortened development periods.
Thankfully, it doesn’t have to be this way.
Create a Manageable Project Timeline by Focusing Expectations on Critical Functionality
Your stakeholder doesn’t want to overload you with more work than you can complete within the project timeline.
He doesn’t want to force you to compromise quality and deadlines to implement bells & whistles.
So why does he keep doing both of these things?
Because…
- He doesn’t know what IT is capable of delivering within the project timeline.
- He doesn’t know what features are truly critical for day 1.
As an IT professional, only you have the information required to define a reasonable project scope. At heart, your stakeholder knows this. Which is why if you say “Yes” to all of his requests, he’s going to assume they are all reasonable, and he’s going to keep filling up your crowded project timeline with features and functions.
It’s up to you inform your stakeholder about what’s reasonable. Manage his expectations. Educate your stakeholder about what’s critical, and what isn’t. Because when it comes down to it…
Your stakeholder wants bells & whistles, but he needs critical functionality—and it’s up to you to remind him which is which.
Here’s an effective method to do just that.
Use this Pair of Simple “To Do” Lists
With a pair of simple “To Do” lists, you can reach consensus with your stakeholder on what’s needed to launch the system, and what isn’t.
- Open your project’s features list.
- Split it in two.
- Name one list “Critical Features for Day 1”.
- Name the other “Nice-to-Haves”.
- Schedule a meeting—ASAP—with your stakeholder to divide your current features between these two lists.
This last step is critical, yet easy to overlook. Divide this list with your stakeholder, and not on your own. If launch day arrives and you hand your stakeholder a system that’s missing 80% of the features he expected, you’re going to find yourself in hot water. Work with your stakeholder to split up your features list, and get his signoff on what system functionality you are actually on the hook to launch with before you deprioritize everything else.
Once you have clarity on what items are “Critical Features for Day 1”, and what are just “Nice-to-Haves”, your next steps are obvious:
- Focus all your resources on completing your “Critical Features for Day 1”.
- Don’t touch your “Nice to Haves” until your Critical Features are complete.
- Whenever your stakeholder comes to you with a new request, pull out your two lists—on the spot—and define where the new request belongs. (Read this article for more guidance on prioritizing surprise requests.)
That’s it. Though, of course, truly ambitious IT pros will take one final step:
- For your next project, start with two lists.
