Prioritizing Projects at the Program Level
Have you ever imagined what it would be like working in a company where you were literally supporting 3 to 30 active projects at the same time, having to juggle multiple “critical” tasks, and somehow prioritize all of your work to meet the company's strategic objectives? How would you know you’re working on the right task at the right time, so as not to accidentally delay any of the projects, and how would it feel to have everything seem equally urgent, all the time? Believe it or not, this happens more often than you might think...
How do people prioritize tasks without a strategic framework in place?
Without a clear project prioritization framework in place, I have found that people self-prioritize their work based on:
- Who is pounding the table and yelling the loudest; or
- Who they like to work for or is the most charismatic (people they like); or,
- They choose to work on tasks that are quick and easy to complete (the proverbial low-hanging fruit); or,
- They choose to work on things they enjoy doing vs. those that are not so desirable (but perhaps more important and urgent).
Naturally, if they’re working on the wrong thing at the wrong time, they may unknowingly be (likely) delaying one or more projects.
Project prioritization at the program level
So how do you stop the madness? Project prioritization at the program level needs to occur based on the business’s strategic objectives. However difficult this process is -- and I can assure you, it is difficult simply because not all projects can be priority #1, in fact, only one project can be #1 -- the payback is huge.
Companies that have a clear, strategic project prioritization scheme experience significantly higher product delivery rates and therefore higher revenue. And after all, isn’t that the name of the game? Delivering the right product, with the right quality, to market, faster than the competition?
The realization
This exact realization recently hit me right between the eyes – it was as if I’d been looking at something only to suddenly become aware of what I was seeing. I was working with a client that had requested a free trial of PLAYBOOK. With the best intentions, we planned their active projects in PLAYBOOK. As we were doing so, collaboratively with the team members, we naturally stacked the projects on top of one another not considering the workload on the resources.
The teams began executing daily standups and were making more progress on their projects using Playbook than ever before. But as I began looking at the loading on the resources, I realized just how overloaded the system was. Overloading teams with work is like trying to push play-doh through a small pinhole. Eventually you will squeeze some play-doh through, but it’s a very slow and painstaking process and output is extremely limited. In addition to the people being overloaded, another result of the lack of project prioritization was that there was a daily discussion about which project task was the right one to work on next, especially for the shared resources like the Quality and Test engineers.
Obviously, there was a tremendous amount more potential. But before Playbook could have an impact at that level, the company needed to prioritize work at the program level.
The process
We looked across the sea of active projects and made some tough decisions about what projects to assign top-level priority, while other projects were placed either on the back burner or in the backlog. It was agreed across the organization that back burner projects were only to be worked on if there was nothing else anyone could do on a top-level priority project. The projects in the backlog were not to be worked on by anyone until they could be either moved to the top-level or back burner, and only as people have the capacity to work on them.
The result
Once the project prioritization process was completed, priorities became crystal clear to everyone, so there was much less task switching and much more focused effort on the most important task of the day. Scaling back the number of active projects is like a highway with little traffic, flow rates are much higher so projects are completed at a much, much faster pace. Teams were enabled to push the play-doh through a lot faster because the pinhole had disappeared. In this scenario, everyone wins – people, a company's greatest asset, have clear priorities every day, feel empowered, and energized and the business knows its strategic objective is being met — adding profit to the bottom line.
The lesson
With the best intentions, a project team is only as productive as the system allows them to be. Less work means more output, at a faster pace. Delivering the right product, with the right quality, to market, faster than the competition is what matters. Once priorities are set at the strategic level and the workload is properly balanced, Playbook can make a real difference in terms of speeding up delivery at the project level.
Want a deeper dive into the benefits of Playbook? Watch the demonstration video.
Related articles
Guide to Lean Project Management
Guide to Lean Product Development
Science and economics behind “failing fast”
Lean Product Development the Opportunity of the Century.
Lean Product Development Case Study
Principles of Lean Product Development
Lean Product Development Value Chain
Get started with Lean Product Development
Lean Product Development: Cultural Resistance
4 ways to Ensure Your Lean product Development Initiative Won't Fail
