Kind and Cruel

by jed simms on October 27, 2011

The human body is both kind and cruel in that, for example, in the event of an emergency it will allow us to make a mad dash for safety (kind) and punish us later when our muscles seize up (cruel).

Our project delivery approaches are also kind and cruel. They will allow us to make a mad dash to completion (albeit at times over many months) and then punish us later when our operational options and flexibility seize up due to system and process constraints.

We long ago discovered that the opposite to project ‘success’ is rarely failure but ‘compromise’ — significant compromise not only in project delivery performance but also, and more importantly, in compromised future performance.

The delivery of the solution by the project is the start not the finish. It is the start of what you can do with that solution. Unfortunately with most of our performance measures focused on completing the mad dash to the end of the project, the longer-term business consequences are too often compromised.

  • Scope is treated as a variable – to be adjusted to meet the budget or schedule
  • Functions and features are defined that ignore their implications on the end-to-end processes
  • Design decisions are made to meet technical standards at the expense of operational costs and productivity.

And so on.

While consistently reports of poor project performance are measured in terms of time and budget overruns, the most significant cost is the deficiencies, compromises and constraints that are delivered to the business. Read the rest of this entry »

SIMPLISTIC v SIMPLIFIED

by jed simms on October 19, 2011

The (late) Steve Jobs said that if you believed something was ‘simple’ you obviously did not understand it. The challenge, he said, was to thoroughly understand the complexity so that you can then simplify it. His products are testaments to his success — highly sophisticated items of technology with one or two buttons only, for example. Apparently he and a small team spent their evenings for weeks and weeks simplifying the original iPod interface.

Yet in our time-pressured working environments, increasingly there is a desire for the simplistic.

A classic example of this is the approach of locking business case defined benefits into future operating budgets so as to ‘ensure their realization’. This is simplistic thinking – and illustrates the value-destroying properties of such simple thinking.

Locking benefits into future budgets:

  1. Reduces the value of benefits as managers seek to minimize their future exposure by defining only enough benefits to get their business cases approved (not a good start).
  2. Is irrelevant to the many managers who do not expect to be in the same position by the time the benefits are being expected (not a behaviour changing solution).
  3. Fails to recognize reality – that during the course of the project and beyond the financial value of benefits can legitimately change significantly due to factors outside the project and governance teams’ control – eg interest rate changes. Any increase or decrease in value is ignored by this simplistic approach.
  4. Doesn’t even measure benefits realization only budget achievement. If other events have allowed the future budget to be met, the benefits from the project may not be realized at all as they are not needed (to make budget) or measured (as benefits).

And we could go on. But this example illustrates the dangers of simplistic thinking.

Simplified thinking, however, is quite different. Read the rest of this entry »

Are your staff ‘protecting’ you?

by jed simms on October 12, 2011

Are your staff ‘protecting’ you?There is a famous case in Australia where the Chairman of a large company rejected out-of-hand a takeover offer of $27 per share when those shares twelve months later were trading at under $10. This Chairman’s ‘protection’ of the company was hugely detrimental to his shareholders.

So it is with the project fraternity and project improvement opportunities. “Oh, THEY won’t adopt any of this” or “We (as an organization) are not mature enough (to improve).”

In one case the project manager dismissed the TOP approach to identifying and simplifying the business requirements as “Just too hard to do in this organization.” His project then went on to double its original cost and then fail due to, you’ve guessed it, inadequate business requirements! I’m sure his Sponsor was delighted to have been protected from a workable and lower cost solution.

There is a common but fallacious belief that ‘more mature’ (as they are seen) processes are more difficult and more work. In some cases this may be so; but with TOP we’ve designed it to remove many of the redundant steps and render other steps unnecessary. The overall workload goes down.

If you take an 18-step process and redesign it to be a 5-step process or reduce 375 processes down to 23 options – the design, configuration, testing, training and operating effort and associated project costs all go down. But most organizations are ‘protected’ from this level of improvement by project teams’ use of software as the definition of requirements. Read the rest of this entry »

Quality sliders

by jed simms on October 7, 2011

Many years ago I saw a specification for a “sub-second response time nationwide” for a notification of staff absence to HO transaction. This was a transaction where a three-minute response time could have been tolerable.

The person specifying this performance level had no idea of the costs associated with meeting this request.

This event prompted me to develop a guide for executives that spelt out the cost implications of some of their unthought through demands.

In view of the desire for sliders, I have converted the quality performance dimensions into a set of sliders. There is no mutual exclusivity, they merely show the tradeoff between quality/performance and cost – the higher the quality standard, the higher the cost to supply and maintain. Simple.

These sliders are intended to give business management a mechanism to control their systems costs. As systems are invisible in their nature there is an unconscious belief that their quality options are free. If you want 24/7 availability, that comes with a cost. At least a discussion can be held as to the level of quality you’re willing to pay for.

For more information and detail on each option – see How to control your systems costs.

This brief Guide gives Project Sponsors, and their governance teams, information on 12 key system cost drivers so that they can specify their systems performance and cost criteria on business terms.

This Guide puts the business in control of its downstream systems costs. Buy now

Sliding to disaster

by jed simms on August 18, 2011

A tool gaining popularity is Rob Thomsett’s sliders.

The idea is simple: there are six sliders/options that measure project success with a scale of 1 (low) to 5 (high). At the outset of the project the business is asked to rate the relative importance of each of the six options with the caveat being that any movement up on one option must be met by a corresponding movement down on another.

The six sliders cover

  • Stakeholder satisfaction Do you want to be satisfied with the outcomes of the project?
  • Deliver on time Do you want to receive the project to schedule?
  • Deliver on budget Do you want to receive the project at the agreed cost?
  • Deliver planned scope Do you want to receive all that you said you wanted?
  • Meet quality requirements Do you want it to perform/work?
  • Team satisfaction Will you feel warm and fuzzy if the project team are happy at the end?

Now remember, any movement towards “Yes” must be countered by a corresponding movement towards “No”.

This is surely the ultimate substitution for project performance!

“Mr/Ms Business, we are about to take your $x and in return we want you to commit to being happy with a poor quality result that you agreed to be dissatisfied with, but know in return that the project team had a great time.”

Interestingly, project practitioners welcome this model but complain that only dimension reflects the project team (team satisfaction). Within bounds, the business is not interested in ‘team satisfaction’. Did the team have a good time? Is not a business measure of success. (This is not to say that managing team morale and productivity is not important.)

This model seems to me to be evidence of how far away we are getting from what projects are all about — delivering business outcomes and their benefits.

The measure of success is “Did the project deliver the agreed (hopefully optimized) business outcomes so as to enable the full realization of the associated benefits?” There is no sliding away from this measure. Read the rest of this entry »