Leveraging Project “Constraints” and Maximizing Results
As a project manager for demand-driven, lean manufacturing software, I have more than a nodding acquaintance with the theory of constraints (TOC). What I find quite remarkable is the ability to apply the theory of constraints to other mediums beyond the manufacturing of goods – even something like project work. When a client understands the theory’s principles, it can be powerful in driving a truly transformational project that outperforms their other software installations. It becomes a new way to frame how you and an organization collaborate to create something new – a better business with better and faster results.
If you want to learn more about how constraints management works in manufacturing, definitely check out my fellow blogger, Rick Denison. He’s the go-to guy for this practice on our site. What I’d like to talk about today is constraints management during projects—specifically—what are some of the more common project “constraints” and how do I deal with them?
Every project contains a standard set of parameters that become initially defined, but are continually balanced throughout the project lifecycle. These are competing project constraints, which include, but are not limited to:
- Resources, and
These elements will pull against each other throughout the project, but it’s wise to identify them not as “bottlenecks” or issues, but as constraints that can be leveraged to drive outputs and faster progress. To give you some ideas about how to leverage these constraints, I will focus on three from the list: schedule, resources, and risks.
Schedule Time to Schedule
Sometimes people consider project planning a phase that can be glossed over so that the “real work” can begin sooner. Talking about the work does not accomplish the work, but it will make you consider ways to work smarter. Working smarter means different things to different teams, but can include creative scheduling solutions like:
- Several “sprint-like” mini projects instead of one big define-and-deploy project. This mini-project approach can mean functionality is delivered to business users faster and in more palatable scope amounts.
- Parallel paths of work to get more out of the project timeline.
- Understand the benefits of building in purposeful “buffer” time, which can at first seem like it’s unnecessary or that there’s no time allowable. I encourage teams to do this so that they protect the most constrained project resources and create a project system that is able to handle the inevitable, yet “standard” project disruptions, such as new business climate factors, changing team members, etc. Buffers are central within the TOC framework. Since the constraint resource becomes the pacemaker for the rate at which project deliverables are output, building in this time becomes critical to remaining on-time and not slipping in either schedule or scope.
It’s easy for a project team to complain about not having enough time in the schedule – even if they are just starting out. Instead, think about the full project timeline as a blank canvas and an opportunity to get creative on how to best leverage the time.
Your Most Valuable Resources are People
Your project team is about finding the perfect combination of two elements: quality and quantity. The “quality” of your team members cannot be overvalued. Capable team members that know their role, the business needs, and can deliver on the project objectives are the most valuable assets that any project could ask for.
But even top-performers only have so many hours in the day. Whether team members are allocated 25% or 100%, the important thing is to maximize the time, or capacity, that these resources have available. It’s not about labeling your most “valuable” resources, but inevitably, one team member will be a constraint. So, acknowledge the constraint and have everyone rally around the team member(s) to support their activities. In my experience, that means doing everything I can as a project manager to align tasks, schedules, and being extra-prepared for these specific (and valuable) resources.
The second leverage point to boost your project resources would be to add capacity by increasing the “quantity” of resources. When you have fully maximized the results from all of the current resources and are still not meeting the project scope, many teams consider relieving the constraint by increasing headcount. While this can be a helpful solution over time, be aware of the upfront time associated with bringing more people up to speed and that their output quality may not initially match others. Just like a manufacturing environment, additional resources (machines/assets) add to capacity, but require management and attention too.
Consider project risks to be like identifying project “flow disruptions” — ahead of time and concurrently adjusting course to mitigate those disruptions. Risks can range from small to significant, but discussing them openly and planning accordingly can sometimes be enough to avoid them all together. This means you increase the overall velocity of your project when you deal with less surprises downstream and you are able to deliver results to the business faster and with more clarity.
A team that does not spend time identifying risks throughout the project lifespan will likely regret it at some point. Discussing project risks can seem like more time taken away from “doing work” or a “gloomy” way to kick off a project, but it’s actually incredibly productive. The project paranoia that people raise can seem like an energy drain, but pay attention because often these concerns are based off of real experiences and legends of projects past from which the current team can learn.
The act of going through risk identification can surface two categories of topics. The first category is the potential risk scenarios for which a mitigation plan should be developed and executed. These would be the most common notion of project risks that people consider – the “what-ifs” and their consequences. The second category are issues that may seem like risks, but are really actual and necessary project tasks that were overlooked in the project plan. Be grateful that these were identified and plan them into your project activities like everything else, with a pat-on-the-back for your thoroughness in planning and the confidence in knowing you delivered a higher-quality output.
Next time, we’ll take a deeper dive into the project risks category and talk about ways to overcome them. Until then, feel free to send me your questions or experiences on anything implementation related.
 PMBOK Guide, 5th edition