10 November 2009

Project Management - the trinity extended

Project management fundamentals teach us that that project management was a trade-off between the trinity of:
  • Schedule
  • Scope (requirements)
  • Resource (people, competency of people, and money)
The three dimensions are in equilibrium and each dimension is proportional (inversely or directly) to the other two.

Formulas like the Ideal Gas Law (PV=nRT) work well to simply communicate the basic relationship between pressure (P), volume (V), and temperature (T).  Very abstractly, project management fundamental values might look like the mathematical formula:

Schedule * Resource = Scope

For example, if Schedule is decreased, then Resource must increase (inversely proportional) and/or Scope must decrease (directly proportional).

Each of three values are only so elastic. To be a practical formula, none of the values can be extremely low (0) or infinite.

Customers/stakeholders may only control one or two of the above three. Not all three. If stakeholders try to control all three and the estimates for all three are reasonably correct, the project will fail.

For example, "scope creep" results when the scope is increased by stakeholders that don't want schedule or resources to increase from your original estimates. The formula indicates that this simply isn't possible and scope creep alone (without compensating by increasing Resource and/or Schedule) will cause project failure.  Note that increasing Resource can also be delivered as improved Resources (e.g., same headcount, higher quality but more expensive staff).

There are three other important dimensions. They are derivative from the above three, but important enough to warrant their own explicit treatment. They are:
  • Quality
  • Risk
  • Technical "Balance"
Expanding the formula, it now looks like this:

Schedule * Resource * Risk * Technical Balance = Scope * Quality

(Note: I use "Technical Balance" rather than "Technical Debt" as I believe in at least some areas you can "future proof" or "over architect" to create a positive/credit balance that may or may not create yield at a later time.  This is akin to the agile tenant of "only build what is required" versus "I *know* we're going to need this in a year, and it's a lot more efficient/cheaper to build it now."  It is also similar to cash sitting in a bank account that you're not investing in a way to maximize yield.  Regardless, a tip-of-the-hat to Ward Cunningham and others on the concept of technical debt, it's brilliant.)

Examples of putting these derivative values into play:
  • Decrease quality to reduce schedule (e.g., launch sooner and let the customer test for us; we only fix what the customers complain about)
  • Create technical debt to reduce resources (e.g., don't bother with code/build tools, don't bother with reducing code duplication or code quality refactorings)
  • Reducing the scope allows us to reduce the risk (e.g., of delivery) - the less to deliver, the lower the risk
The above 6 project management dimensions are about managing participant and customer expectations - making sure the trade-offs you are making in the project are transparent to the customer/stakeholder so they can make better decisions to guide the project.

You could use these 6 items in project status reports or at least during major review points with customers.

Update May 2010

There are emerging approaches in software development coming from the manufacturing world (Toyota) which claim to be tearing down the "time, quality, money - pick two" formula and re-writing the laws of engineering and hence software development.  These practices have been adopted into so-called "lean" practices.

  • The old schedule-scope-resource formula holds, but only if you don't include a time dimension.  Schedule-scope-resource continues to apply in a short period of time, but not in a long period (e.g., due to trading out scope/quality for few resources and tight schedule).  If you are delivering a single shot software, the formula works.  If you are going to live with that software for a long time, evolving and extending it, then you have to include.... time... in the formula.  The time horizon is a business decision.  You educate your business counterparts on technical debt levels, and let them decide.  
  • Good non-tech business leaders responsible for a business that uses tech to power the business must develop an understanding of how to make these tradeoffs, no different than being able to assess balance and P&L sheets.  If they can't do this, they won't be effective leaders of a tech heavy business.  I have yet to work with a business leader that has a time horizon greater than a year, and it's probably closer to a quarter (especially with publicly traded companies: shareholder horizon = board horizon = CEO horizon, and so on).  At least in Internet Gambling, the business doesn't seem to prioritize "built to last" over "get me X right now!!".
  • By including "technical balance" in the above formula, which captures changing technical debt due to scope/quality versus resource and schedule, there is an implicit temporal aspect to the formula.
  • Some technologists prefer to root cause all defects, maximize learning as the business progresses, and keep a very firm, low-debt foundation under them.  However, the reality is that many early stage businesses have to make trade-offs every day between enabling future scalability versus doing whatever it takes that week to get a sale made or acquire a few more customers.  The alternative is the business runs out of money and its game over for everyone.
  • Unless business/board leaders are extremely confident of the business proposition, they are not going to invest heavily in future-proofing the business.  This comes down to the business leaders making the right guesses and being in the right place at the right time (note here the debate between user centered design versus good/lucky business leadership - either is valid in the right circumstances, but bring both together and wow).  Great business leaders being in the right place at the right time is a fairly unique combination.
The formula could have a stronger time basis added to it.  You can't (e.g.) inject money into the formula and instantly increase quality and scope.  It generally takes time for a change in one variable to ripple out to adjusting the other variables.  The same applies by gradually downsizing the team - things don't necessarily start failing immediately.  This is an inertia, latency, or lead time effect.  However, you can minimize the time required to (e.g.) inject new talent onto a team by prioritizing as a requirement the ongoing creation and maintenance of tools, processes and techniques that facilitate insertion/deletion of talent onto a team.

The time basis could also be included from the perspective of the time-value of the scope being delivered.  From a competitive viewpoint, it's likely that having the output right now is of highest value, with scope value decreasing as schedule increases.  This is no different than building a new building - once the decision to build is made, every day the building isn't earning money is lost revenue.  The faster you try to build it, the higher the costs - there is a cost/revenue sweet spot here, but difficult to identify in advance.

Another huge variation is that not all resources are created equal.  Some resources can even create a net productivity loss.  Similarly, as resources mature in a team and learn the codebase/technologies, their efficiency increases.  Therefore resource effectiveness becomes it's own formula that replaces the simpler "resources" in the above main formula.

The formula also doesn't fully capture project "success".  Success comes from successful project execution (formula captures this well enough), but not whether the resultant delivery is successful (e.g, with a customer, in a market, creating positive revenue).  A successful delivery is half or less of the battle.  Creating a product valued by customers resulting in healthy and sustainable net profits is really the battle to be won.

1 comment:

  1. This comment has been removed by a blog administrator.


Note: Only a member of this blog may post a comment.