Tag Archives: product management

Project Management Triangle — Redux

A co-worker recently blogged about a classic metaphor of the “iron triangle” whereby the three conflicting pressures of resources, scope, and time are interlocked. The rationale goes that only by loosening one of the pressures will you be able to affect the other two.

This metaphor is usually used by those who have the unlucky task of managing software development projects. It works wonders when presented as an inspiration to motivate the team at sprint launches.

It is when teams try to apply this metaphor in practice, they often find that the triangle is not as flexible as they were led to believe. The date is non-negotiable. Scope? No, customers expect a certain feature set. Can we get more people? The ramp-up is too time-prohibitive and besides we have tons of other projects that we need to deliver, so… no.

Despair. Death march.

Happy Happy Fun Times

The only way out of this morass is honest, deep, challenging conversations and creative thinking. More often than not, code is the least complicated part of the solution.

As I’m fond of saying, if it was easy it wouldn’t be called “work” it would be called “happy happy fun times.”

I think the iron triangle still applies, though to figure out how to move each of the corners, we need to zoom in.

Resources People

Talent – Some people are just naturally better problem-solvers. You know who they are in your company. Bring as many of them as you can find.

Experience – People have varying degrees of familiarity with the system or the business domain. They will help smooth out rough spots when first starting out. But be sure to balance this with some total n00bs to spread the good knowledge and bring in fresh perspective.

Personality – I’ll go ahead and say it even though it may be unpleasant: you want a dynamic team, not a bunch of loners forced to sit next to each other. You want people who are good at communicating both verbally and non-verbally. You want people with a generally outgoing demeanor. Cultivate these qualities, work on them, challenge your people to loosen up.

Scope

Width vs Depth – It’s understandable: customers expect certain new functionality, sales is clamoring for shine and customization. But consider how deep does each feature need to be. Is there a simpler approach you can take to satisfy end-user’s need? Ask yourself what you would do if you only had a week to implement this feature? A day? 4 hours? An hour? Take that hour and build a working prototype of your idea. Show it to your product owner. It will never be good enough to ship, but it will force the product owner to rethink whether they leaked too much instruction to the team as to what they expect to see. This will also force you to actively participate in discussions and deeply understand the user’s need.

Dependencies – If you think the user-interface card depends on the logic card which depends on the database card, stop! You’re heading into a swamp. Features depend on each other, deployment layers do not. Each card should consider the full flow of user experience: from user interface, to logic processing, to data persistence, and back. Start with minimally viable parts of the flow: instead of a fully featured form, start with a form with just one field. Follow it up with dependent cards that build on top of that form. Stay strong when cowboy engineers push back with “…but it’s just a couple of dumb fields, it’s so simple” — that’s how complexity creeps in.

Visibility – Time and time again I’ve seen engineers (myself included) grab onto the work they understand very well and burn through it, with eyes glazing over when product owner mentions areas that sound complex. It’s only human nature: we’re afraid of the unknown. Fight that ferociously. Demand that your product owner lay out the entire project in front of your team. Work towards deeper understanding of all areas. Split off into sub teams to build prototypes for each area, form intelligent questions, find conflicts, do whatever it takes to ensure that everyone can describe everything the team is working on without BSing. Having this information upfront is absolutely invaluable as milestones start approaching.

Time

Embrace Deadlines – I love time constraints. They force everyone to cut out the crap and harness the adrenaline rush to reduce their work to bare essentials, no more no less. If you’re pissed that people keep setting dates for you, get in front of them and set even more aggressive limits for yourself.

With the time pressures as your guide, you can NOW start thinking about how to start pushing the corners of the iron triangle.

A fluidly functioning team full of outgoing people will be able to absorb additional people with little problem. These new people will be able to start becoming productive immediately because you can give them features that don’t depend on other features and because the features you give them will be well-defined and understood by the larger team.

With everyone feeling free to challenge every requirement and thinking of what is minimally viable, you will find most of the system spreading out very fast yet staying malleable because this wide set of features is still very shallow. Now you will be in an enviable position to decide more strategically which parts of the system you want to continue enhancing.

You won’t even notice that the deadlines have come, and they will be nothing more than a pleasant surprise.