The problem w/ “gold-plating”

We had a discussion of gold-plating in project management during my leadership team meeting last week.  To refresh everyone’s memories, here’s a good, if informal, definition of the term (link here):

Gold plating is what we call it when the project team does work on the product to add features that the requirements didn’t call for, and that the stakeholder and customer didn’t ask for and don’t need. It’s called “gold plating” because of the tendency a lot of companies have to make a product more expensive by covering it in gold, without actually making any functional changes.

Andrew Stellman at Building Better Software has a post on why gold-plating is a bad name (post here).  It is an excellent discussion of what the right analogy is — he goes with a combination of gold-plated (a purely cosmetic veneer) and “gilded” (encrusted with useful, but largely-unused features).  Andrew’s bottom line is that such features are “just wasted effort, at least from the perspective of the person paying the programmer’s salary”.

I would say the bottom line is even more stark: gold-plating or gilding not only wastes money, it risks delivery of core deliverables.  Enterprise software projects usually must be delivered by a date certain.  I’ve found that development teams that get distracted by superfluous gee-gaws do so at the expense of priority features.  In other words, not only does gold-plating waste money, it diverts resources from ensuring that deliverables conform to requirements.

Perceptions and Stakeholder Management

I very much like the sentiments expressed by Claude Emond on the Reforming Project Management blog. (post here, blog here).   Too many project managers assume that delivering high-quality work product ensures a high-quality project.  Claude explains how stakeholder management affects perceptions of quality:

[P]roject quality, a strong indicator of project success, does not only depend on the physical characteristics of project deliverables, it also depends on HOW they were delivered. It means that a project is not only a destination, it is also a journey. It means that in matters of quality, BOTH the journey and the destination are important.

Doesn’t that make sense?  The final destination may be your ultimate goal; but how many on-time, on-destination trips have you made where a terrible travel experience ruined the entire trip?  In that light, shared positive perceptions among stakeholders of the project, its goals, its deliverables, and how you got there are the real criteria for project success.

Sustaining the Value of Project Management

As promised, I’m going to blog on the Researching the Value of Project Management study that PMI will release soon (preview PDF here).  This conclusion about value growth and persistence struck me first:

Where Value Is Being Sustained And Continuing To Grow, There Is On-going Focus And Improvement Underway

Well, that sounds a bit obvious. One would expect that value would grow with “on-going focus and improvement”. But is value already demonstrated and delivered automatically “being sustained”? The answer apparently is “No”…

Organizations That Stop Focusing On Value, Or Believe That They Are ‘Done’:
– Stop demonstrating value
– The act of not enhancing value appears to destroy value

Ah… now that’s something to remember. Our PMO fell into this trap.  We thought our “Level 2” project management training was just fine, thank you. Unfortunately, our customers didn’t think so.  It got to the point where one of our most important regions developed its own training to replace ours. 

Some of the value decline was real: our training missed topics that had emerged since its development.  However, the most critical part of the value decline was perceived.  Our unwillingness to address pain points — and the need for one of our customers to become self-sufficient — undermined our relevance. 

The bottom line is simple.  If my group doesn’t stay focused on sustaining and building value, people start to ask: Why do we have a Global PMO anyway?

Project debriefs…the Army way

Nice post on after-action reviews (AARs, or what we call reviews or debriefs) by Ed Kless at VeraSage.  Ed relates the experience of an United States Army officer in his class (post here).  I especially liked two points:

At AARs all personnel remove their hats. This signifies that in the AAR there is no rank. Insubordination is not possible.

While there is no rank, junior ranks are encouraged to speak first. Often times they are the ones who see the problems and therefore possible solutions more clearly.

Also, Ed’s student provided a copy of the U.S. Army’s manual (here).

Hat tip: Dennis Howlett

People factors in managing consultants

Elizabeth at A Girl’s Guide to Managing Projects blogs (here) on a recent Forrester report (report abstract here) on people management in large IT implementations in Australia and New Zealand (ANZ).  As she notes, it is a useful twist that they focused on the challenges of managing third-party consultants.

I haven’t read the report, but it looks like it has some sound recommendations.  In particular, this suggestion may sound obvious: one should provide an “[i]ntroduction to your processes and procedures to ensure that the external consultants know how to raise issues and track progress.”  It can’t be that obvious, because I’ve seen exactly one customer who did so.

One caution about the study: the ANZ SAP consulting market is white hot.  It is probably useful that Forrester looked at such a challenging market.  However, keep in mind that some of the issues they describe may be driven by the tight market itself.

Upgrade tips…what’s worse than a modification?

I was going through a list of upgrade tip articles collected by Demir Barlas (here) in his SAP Watch blog (here).  Most of them look unobjectionable, but one touches on a pet peeve.  Amit Jain calls them out here (original SDN post here):

6) Cloned programs — Cloned programs are customer programs copied from standard programs… [they] are coded by copying the standard program to a Z-program, having the standard includes or standard function modules.  This causes issues after the upgrade, because the standard includes or functional modules might not work with our custom code.

Clones are insidious, because developers don’t think they’re system modifications.  They’re right: they’re worse than system modifications.  I’ve never heard a compelling case for cloning.  Directly modifying the standard program — while not exactly encouraged by SAP — is a more straightforward and honest approach:

  1. There’s no more pretending that a clone isn’t a modification.   Taking standard code, modifying it, tacking on a “Z” to the name, then claiming it isn’t a modification seems disingenous.
  2. Clones hide from SAP monitoring and other system features.  In an upgrade, SPAU has features that attempt to account for mods when updating the code base.  It is much simpler to deal with mods in SPAU than by searching through the new SAP program.
  3. Clones create non-value added work.  For example, all of the dependencies to/from the cloned program have to be re-established manually during an upgrade.  Never mind the manual bookkeeping involved…

Value of Project Management Study

One of my first duties with the PMI Global Corporate Council was to give feedback and input to Janice Thomas, who was planning PMI-sponsored research into the value of project management.  After more than three years, it was great to see the first findings made public in Warsaw earlier this year.

The study itself, Researching the Value of Project Management, will be released soon.  Smartly, PMI released a preview PDF (here) and a 90 minute presentation by the lead authors Janice Thomas and Mark Mullaly, PMP (embedded here).

Mary Adams over at Hybrid Vigor will be particularly interested in the attention paid to intangible benefits (Crossderry posts here, here, and here) in the study, which Kelley Hunsberger highlighted (here).

Pressure, Error, and Leading Project Escalations

While we’re on escalated projects it’s a good time to hearken back to Dietrich Dorner’s book on The Logic of Failure: Recognizing and Avoiding Error in Complex Situations.   Such projects are a high-pressure leadership environment, for sure.  It is critical to have no illusions about what lies ahead, especially in the Discovery (here and here) and Decision (here and here) parts of the leadership pyramid.

Ken Thompson’s The Bumble Bee blog at bioteams.com highlights two “tangents” identified by Dorner.  These are common leadership failure modes, largely because they are very tempting to pursue during a crisis.

We may resort to “horizontal flight,” pulling back into a small, cozy corner of reality where we feel at home … Or we may resort to “vertical flight,” kicking ourselves free of recalcitrant reality altogether and constructing a more cooperative image of that reality. Operating solely within out own minds, we no longer have to deal with reality but only with what we happen to think about it.”

Read all of Ken’s post here.  Note his great tips on how to deal with a “flying” leader.

Delivery — 5th “D” for Leading Project Escalations

Good leadership never passes the buck… — Anonymous

The hardest part of an escalation is commiting to it; just like the first steps someone goes through when confronting crises such as alcoholism, drug addition, chronic smoking, etc.

Recognizing the need to change and the unmanageability of your situation — the first step of a typical 12-step program — corresponds to the Discovery layers of the Escalation pyramid.

The Discovery, Definition and Dialogue layers correspond to the second, third, fourth, and fifth steps of such programs:

  • Coming to believe that something outside of the project can “restore the project to sanity,”
  • Making a decision to turn that part of the project over
  • Taking an inventory of what is wrong (and right) about the project.
  • Admitting the faults in that inventory to another.

However, once the ball has started rolling, the situation becomes more normal. In other words, you manage an escalation just like any other project deliverable: plan, execute, monitor, control, and hopefully, close.

Dialogue — 4th “D” for Leading Project Escalations

 “AND to be able to explain it …” — Pericles on leadership

The great Athenian recognized that leadership required mastery of analysis and rhetoric.  As one figures out “What is to be done?”, some explanation and dialogue is inevitable.  But once you know what to do, one must carry the message to the world, and there is a way to deliver bad news.

Rule Number 1 is to save bad news for private meetings.  It just doesn’t make any sense to jump up in a public forum, though I never cease to be amazed by the number of folks who don’t understand that one should never criticize your superiors or their ideas in public. A great and simple tip from ArLyne Diamond from an interview (here) to short-circuit a potential pitfall or misunderstanding is that:

If you learn about the idea in a meeting, try to get the topic tabled with a suggestion that some research about it might be helpful.  Take your boss aside privately and share what you know in a friendly, noncondescending manner

%d bloggers like this: