Troubled Projects and Engaging Change Stakeholders

Glen at Herding Cats (here) points to a Center of Business Practices study (here) on the causes of troubled projects.  I’ve posted on some of our own findings about project success (here and here), but I haven’t elaborated on what we’ve found about the composition of change control boards.  Below is an extract from a comment I made on Glen’s post:

Our project debrief analyses have consistently found that the right level of executive presence on change control boards is essential to ensure change is managed, not simply documented. In fact, the lack of such a presence (or regular absences) marks the project as a potential escalation.

When a senior manager vets the prioritization of changes by focusing the project team on the project’s goals and intended outcomes — one should usually find scope, time, and resource changes easier to manage (with fewer, more salient change orders). It also keeps the business invested in the project. Many IT shops resist this measure, but it works wonders once they “get it”. 

Obscure SAP Tools — Upgrade Dependency Analyzer

In previous posts (here and here), I’ve lamented that too many customers and partners don’t know about some great SAP tools.  Of course, sometimes SAP does a good job of hiding them in plain sight.  Regardless of fault, it’s too bad that these tools languish unused on the SAP Support Portal  (registration required if you haven’t already done so).

To do my part to remedy this, I present the SAP Upgrade Dependency Analyzer.  The use case is straightforward: when planning an upgrade of the systems in an SAP system landscape, customers want to know whether the update has an impact on other systems in their landscape.  Such impact might require additional changes.

While it is quite new, I expect it to become an invaluable tool when setting and planning upgrade projects’ scope.

PM Quote of the Day — Augustus Caesar

You cheer my heart, who build as if Rome would be eternal.

Who knew that Augustus was such a fan of quality workmanship?  It is a testament to how well (and how much) Rome’s builders built that we can see so much of the old Augustus’s Eternal City today.  Even hundreds of years of stone poaching, neglect, and the passage of time never completely obscured the glory that was Rome.

This saying reminds me that I should take seriously everything I build… even this simple blog post.  Augustus’s praise is a useful corrective to the idea that what we’re doing today is ephemeral, fleeting, and unimportant.   He isn’t advocating gold-plating (post here). 

From what we know of his views on adornment, haste, and waste,  Augustus valued people, places, and things that were reliable and built to last.  Considering that the empire he left lasted for almost 500 years in the West (and almost 1500 in the East), he knew a bit about permanance. 

Or what passes for permanance in this world.

PMBOK 4th Edition Features — Data models per process

Scope Defintion section of Scope Knowledge Area -- 3rd Edition PMBOK Guide (Copyright PMI 2004)

Scope Defintion section of Scope Knowledge Area -- 3rd Edition PMBOK Guide (Copyright PMI 2004)

When I saw the pre-release PMBOK Guide 4th edition draft, the new data models attached to each process caught my eye. 

I liked the 3rd edition’s attempt to capture data and process flow.  However, the approach was a bit clumsy, largely because it was done by knowledge area.  To be fair, the 3rd does have a set of process group diagrams in Chapter 3 with a decent overview of the flow.

Scope Definition Process Data Model -- 4th Edition PMBOK Guide (Copyright PMI 2008)

Scope Definition Process Data Model -- 4th Edition PMBOK Guide (Copyright PMI 2008)

While the big picture view those diagrams provided was nice — versions of them exist in the 4th edition — mapping the data inputs/outputs by process is more rigorous and intuitive IMHO.  I was OK with  the boxes listing the data I/O, but the models are much more effective visual representations of the individual processes.

I’ve provided a couple of examples of the different approaches FYI.

PM Quote of the Day — George S. Patton

A good plan, violently executed now, is better than a perfect plan next week.

This quote is an nice appropriate bookend to yesterday’s Eliot quote (here).  Most SAP projects have to be delivered within a tight time window within strict resource constraints.  With two legs of the triple constraint almost fixed — and we can’t compromise on quality with mission-critical applications — our scope planning and prioritization must be ruthless. 

While it is important to have patience with ourselves and others, dithering about features and functions doesn’t work in today’s project environment.  To slip in another quote: Say what you’ll do, do what you say… and don’t look back.

PM Corner-Cutting Poll Results — as of 25 Sept

I had 46 49 (51 now) responses to the my survey question “What are the most common areas that are “cut” in projects or programs?” Below is a bar graph with the current results (I’ll keep the poll open for a while on the right-hand sidebar of Crossderry).

In future posts, I’ll have some commentary on the “top” answers.

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.

Don’t forget the “corner cutting” poll

I’m getting some good response to the “corner cutting poll” on the right sidebar of the blog itself, but I’ll leave it open for a while longer. 

For my newsreader subscribers, the poll’s direct URL is here: http://www.polldaddy.com/p/775626/

Business Value Game — Prioritizing Requirements

While I haven’t gone through a live simulation of the game, I like a number of the concepts behind The Business Value Game (post here, game here).  Of course, I love learning through simulation (entire Complexity Set here). 

The game also has players assume the role of salespeople who have to prioritize the backlog that developers will have to implement.  This approach is great for both roles:

  • If you have salespeople play the game, they start to get a better feel for the real consequences of having made unfulfillable promises at deal time. 
  • As developers play the game, they should develop more empathy for the pressure that sales teams feel as they try to satisfy the customer and close deals.

Very promising stuff…  Now, when can I get the time to check it out?!

How much complexity theory can we apply in IT?

I’m fascinated by complexity theory and attempts to apply its insights to the software business.  If you’re interested in those topics you could do worse that to add two bloggers — Jurgen and Bas — to your newsreader (don’t forget about Crossderry). 

Both touch on complexity regularly (Jurgen’s latest here, Bas’s latest here) and they’re clearly big fans of the theory and its implications.  I agree there’s much that’s applicable, especially the concepts of iteration and feedback, which can even be used in “waterfall” approaches (here and here).  My academic background makes me especially sympathetic to the limits of central planning (start here re: Hayek).

That said, I’m not sure we can rely on self-organization for everything.  The most effective models of complex adaptive systems are derived from simple rules that generate complex phenomena.  This approach is mimicked effectively in agile, iterative, and other rapid development techniques (list of SW methodologies here).  Simple feature lists, regular interactions with stakeholders, short cycles, many versions of usable work product, etc. can generate feature-rich and useful applications.

However, the scalability and stability of these applications is often problematic.  IMO, this result is to be expected given the evolution of complexity among living things.  We like to point to complex creatures and structures — e.g., human brains — to support applications of complexity theory. 

But do we remember that most life is still very simple (about half of the biomass is microscopic)?  Also, aren’t complex creatures the ones that have had the spectacular denouements over the eons?  Betting on self-organization isn’t always a winning bet.  As I said, I instinctively like leveraging complexity concepts, but we must remember that they cut both ways.

%d bloggers like this: