In my experience, too many projects are under too much pressure. The sponsors want all of the features, completed in too-short time, with no defects.
And, if possible, the sponsors think the project should cost nothing, the team should not need any training, and the team can work in any way, regardless of the desired outcomes.
I’d like to get something for nothing, too. I have yet to see that occur.
When we define our project boundaries, we are more likely to get something we do want. We might not get everything. We’ll probably get a lot of what we want if we decide how to make tradeoffs.
Let me recap how to get some of what we want and finesse the rest.
What Drives the Project?
I have worked on projects where the managers wanted to keep the team occupied until the salespeople closed a deal that would require all these people and more. That optimization for the team and their capabilities was a rare occurrence for me.
I have also work on projects where the managers felt very strongly about their mandated process. That optimization for the environment didn’t help us finish the work.
I have more often seen one of date, cost, features, and low quality drive the project. I have not been able to deliver both low cost and high features. Or, any two of the four of these possible drivers.
That’s why I say you have one driver, and the rest are constraints or floats.
What Constrains the Project?
Once you have one and only one driver, you have a shot of defining the constraints. As with all challenging decisions, the conversations around these decisions are as important as the decision itself.
Let’s imagine that date is driving your project. And, you want to get as many features that work by that date. I would say that feature set is a constraint. Is there another real constraint?
This is where the question, “If it’s three weeks before the desired ship date” in Part 1 matters.
In my experience, unless you have infrequent deliveries, you don’t have two constraints. You have one constraint.
Yes, I have “cheated” and offered the people who wanted “all of it” more frequent releases. Even when we had boxed software, that was less risky than trying to manage an impossible project.
How Can You Use the Floats to Reduce Risk?
Once you have a project driver, and one constraint, you can use the other aspects of the project pyramid to manage risks.
Let’s assume date is a driver and feature set is a constraint. You might be able to hire more people to either help with the tools the team needs. You might be able to get a team room so the team has a better work environment. You might be able to tolerate more defects which would allow you to meet the date.
Agile approaches help us manage a ranked feature set in a specific time period (even if we don’t use iterations). We don’t get date and feature set—we get some features in some time. And, that might be enough to satisfy the sponsors.
Summary
Whatever you do, do not create or accept an impossible project. Asking the project team to accept that kind of pressure is not professional.
As a manager or project manager, I try to be professional. (I’m sure I’m not perfect!) That means not asking people to work crazy hours, or to work so they don’t have pride in their work.
When we create management and technical excellence, we all win. I’m including the customers in those wins. We might not please the stakeholders/sponsors. And, they need to be professional, too.
When we create a great environment for the team, when we invest in people’s capabilities, when we define the project driver, constraints, and floats, we can create successful products. We might have to use “how little” thinking to achieve that success.
And, the more often we can ship something small, and do it again and again, the more options we have to change the drivers, constraints, and floats.
All the posts in this series:
- Create & Manage the Project’s Bounds, Part 1 (Bounds)
- Create & Manage the Project’s Bounds, Part 2 (Constraints and Floats)
- Create & Manage the Project’s Bounds, Part 3 (Constraints and Floats for Infrequent Delivery)
- Summary for a Project’s Boundaries: Drivers, Constraints, & Floats
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Summary for a Project’s Boundaries: Drivers, Constraints, & Floats Opinions expressed by Java Code Geeks contributors are their own. |
