Do you know your project's bounds? Do you know what your sponsors want from your project?
For many years, I heard about the “iron triangle.” Sometimes, the triangle was “Scope, Quality, Cost.” Sometimes, it was “Scope, Date, Cost.” It was always three things out of a minimum of four possibilities.
I never saw a triangle in practice.
In fact, I often saw six interconnecting bounds that organizations traded off:
- The desired feature set
- The desired quality
- The desired date to release
- The desired cost of the work
- The desired way to work or the actual work environment
- The desired set of people to do the work.
And, every single failed project pretended to set all of those in advance. And, if things didn't go according to plan, any of those “bounds” changed. We shipped fewer features, we shipped later, we released with worse quality, we added more people, we changed where people sat, we spent more money… We did anything we needed to. Those boundaries were not real boundaries.
I wanted to make the real project boundaries clear. I'd seen from these death marches and failed projects that we could not decide all the possibilities in advance.
I developed a set of questions that I called drivers, constraints, and floats. I used those questions to make tradeoffs all the way through the project, so we had a chance to succeed.
When You Have Only One Delivery, Project Goals Matter
Back in the 80s and early 90s, the cost of interim deliveries was high.
We released boxed software. We could not easily update the software unless we sent a tape, disk, or CD.
Everyone suffered from the problem of relatively high costs to update a product in the field. That's why understanding our boundaries was so important.
I often worked on projects and programs where the project goals shifted, especially as we got closer to the anticipated release week.
At one organization, we'd focused on the speed of the product. Six weeks before we were supposed to release, the senior managers wanted to change the focus to more features.
I said, “We can add more features. If we do, we will add a minimum of three months to this release. I think it will be closer to six months, but it takes us weeks to ramp up for new features.”
The managers all said something, “But we need more features. We need them now.”
I suggested they didn't because of where the product was in its lifecycle.
What Does Your Product Need for Quality and Features?
I like to think about Moore's chasm when I think about the product life cycle.
When I think about where we are for the product, we can think about what we want for this project. (See Project Work vs. Product Work for more of how I think about projects and products. I want to keep teams together.)
When a product is early in its life, that product solves problems for many disparate people. That's why time to release is so important. You don't need much in a release, as long as you release often enough to acquire new customers and keep your current customers. It's about market growth.
You need to fix enough problems early so you can attract more customers. And, if you have enough customers and you solve enough problems, you can probably move to more problems as long as the product mostly works.
Once you hit the mainstream, see how the goals change for the product? The customers want a product that works. As long as you release updates often enough, you're okay (that's why time to release is second). You need to reinforce your market position.
As an example, I'm a Conservative for Microsoft Office products. I would be thrilled to never have another update to any Microsoft Office product. I used to say I knew where the problems were and how to get around them. No longer. If I didn't have to use those products, I wouldn't.
However, I'm a Visionary for Affinity Publisher and the other products in that suite. It works well. I know where it doesn't do the thing I want to do. As long as they don't break it with more defects, I'm happy.
I don't ask that you agree with my opinions. I would like you to consider when different customers have different opinions about your products.
That's when we have the sponsor wants everything problem.
What Do You Do When Your Sponsor Wants “Everything?”
Here's a common scenario: It was three weeks before we wanted to release. The next project was clamoring for people. That's when the managers wanted to add more people, or cut scope (already-integrated features), or stop testing.
I rarely found adding more people that late in the project worked. (I have added more people to testing so support had a shot of understanding all the product issues when we released.) I worked on projects where we cut scope and the entire product stopped working.
You can always stop testing if you want to be an ostrich.
I decided to ask questions at the start of the project (which is why I put them in the charter). I developed this set of questions which I first described in Manage It!:
If it's three weeks before the desired ship date and we don't have all the features done and we have too many defects, what do you want to do? Choose one of these options:
- Ship anyway. Date is king. We have to ship.
- Finish the features. Don't stall, don't goldplate, but finish. Features is king.
- Forget the features. Fix the problems so we don't get inundated with support. Defects is king.
Yes, several times, the manager said I needed all three. I said, “No, you get to optimize for one of these. You can't optimize for all of these equally. Choose one as the driver, and the others are constraints. Then we'll see what my other levers are (the floats).”
Sometimes, the manager asked, “Can we hire more people?”
If it was early enough in the project, I said fine and we discussed who and how to hire. I also explained that we would initially slow down our work while we integrated new people on the teams.
I often heard big sighs.
Sometimes, I asked for “special” rooms, what we would now call team rooms. At one company, I asked the program of about 60 people, if we could take over the large conference room, would that help them? Oh, yes. Even the introverts agreed.
I asked for—and got—that big conference room. We arranged desks in rows. Everyone still had their office to escape to. We used that big room for almost two months. Now, I realized I had avoided the Allen Curve of distance.
Notice that I, as the project manager or program manager, enforced the One Big Driver for the work. I'd seen that we couldn't balance everything. We needed to choose one thing that drove the program.
We could manage the other constraints and floats with life cycle choice and risk management.
All the posts in this series:
Pingback: New PM Articles for the Week of January 20 – 26 | The Practicing IT Project Manager