Was software engineering ever alive?

The third phase of reanimating Crossderry

The third phase of reanimating Crossderry

The second phase of reanimating my blog is to re-start reading other bloggers. I gravitated back to Glen Alleman and Herding Cats, where his post Software Engineering is Dead? caught my eye.  Two comments:

Google and Wikipedia are the “shining” examples used by detractors of planning and controls.  Funny that they never reference Technorati — any blogger will tell you how unreliable it is.  Nary a word about the issues with cloud computing reliability that Dave Rosenberg notes here… 

Second, has there ever been widespread use of engineering principles in software design?  Sure, I saw it at SAP and I’m sure Glen sees it in A&D. But is software engineering really engineering?

The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems. 

Great post/thread on Mathematics, PM, and complexity

Glen Alleman and a number of commenters contributed to a great thread on math, PM, and complexity (here). 

I try to keep the ideas of complexity “science” in mind when planning strategy and its execution.  In particular, I have a deep respect for the power of self-organization and the need to create flexible rather than brittle management systems.

However, I’m not sure how powerful CAS really is as a theory, at least w/r/t/ project management.  For example, how do its predictions advance my estimation approach beyond what we’re doing w/ probability distributions (e.g., Monte Carlo simulations via Crystal Ball)?  To I really need math beyond that to get “good enough” estimates?

More on estimation principles

I saw this comment by Dennis Stevens (Dennis’s blog is here) on Glen Alleman’s post on software estimation practices (here).  His comment hit on two points that stood out.

Effective estimating requires a strong understanding of variance in estimating and how to account for/govern this variance.

Ditto and amen… my experience in implementing logistics optimization (I worked for formerly-independent component of Descartes) helped me get comfortable with the fuzziness of estimation (e.g., variance).  Two b-school courses were also helpful: mathematical modeling for marketing and applied multivariate analysis (I keep the latter’s textbook by my desk). This background may not make me an expert, but I have a decent estimation BS detector.

Politically driven estimates are just irresponsible management. I remember a conversation with an executive where I told him “This is a 46 week effort. If you need to say 32 to get funding, then you can say 32 and deliver 14 weeks late – or we can say 46. It’s up to you.” We presented at 46 weeks, got the funding, and delivered on time. If an organization can’t afford to do a project, it shouldn’t be done based on false estimates – this is malfeasance.

As Dennis suggests in this case, pretending that the earlier delivery target does not compromise the product or mean inevitable delays is foolish, even unethical.  My experience is that this self-sabotaging approach happens because the project can’t or won’t demonstrate the impact of such decisions on the initiative’s business case.

To that point about the business case, I’ll use a future post to lay out how we used a simple illustration of our business case to justify an internal program’s proposed release schedule.

Deliverables, work packages, and the schedule

This temptation to fix a schedule and get to work is constant in enterprise IT.  It is particularly alluring for any application tied to a SOX-compliant landscape — some governance models only allow two opportunities/year to deliver – where project durations strongly suggest themselves and time is always “a-wasting”.

Of course, as Glen Alleman reminds us here, starting with the schedule  is wrong.  I won’t recapitulate his post here, but I’ll borrow from his comment to another post which points out the fallacy in this kind of thinking:

[M]any…process improvement projects have failed, along with Enterprise IT, because the WHY of the effort is not established or well understood. The principles establish WHY we should be doing something. The practices of course tell us HOW.

This rush to “get working” short-circuits on of the most important functions of a WBS: stakeholder management.  Properly defined deliverables and work packages aren’t simply inputs to the schedule, budget, etc.  If nothing else, a WBS  is the most accessible framework for a discussion with one’s stakeholders that ensures that the what of the project supports the why of the project.  Wouldn’t it be a good idea to make sure that why and what are elaborated and priorities agreed upon — even at just a couple of levels – before getting down to who, when, where, and how?

Methodology Scaling/Selection Outline

Or maybe I should say “Methodology Scaling/Selection Graphic”… Glen Alleman’s recent post on PM and Agile (here) reminded me to post this picture (click to enlarge) of a slide we use when discussing which methodologies to use for which project.  Note that we do not directly oppose “Agile” vs. “Waterfall” in our continuum.  Sure, SAPScrum is pretty pure agile, but that doesn’t mean that ASAP doesn’t contain agile concepts (e.g., emphasis on iteration short cycles during the Realization phase). 


Also, we’re emphasizing that initiative leaders must be comfortable combining philosophies when implementing solutions, which is why we’re driving program management knowledge out to our general PM community (as implied in the bottom box).

Glen Alleman’s Mission to the Agilests

Dont I look like I should be the patron of desperate situations?

Don't I look like I should be the patron of desperate situations?

I don’t know why I think of Glen’s efforts to reconcile agilests and PMs in religious terms. Maybe it’s because many in both camps see topics as either/or — either you’re with us or against us. Or maybe I worry that it’s a hopeless cause (which is why St. Jude graces this post).

There’s not much I can add to Glen’s latest: If I’m Doing Project Management Right am I Agile?  To me, this question is not either/or, it’s both. The worst misconceptions are around planning (especially the schedule), per Glen’s comments on the Agile Manifesto tenet”Responding to change over following the plan”:

The notion that plans (schedules actually) are developed and then fixed is nonsense on any practical project. There are no doubt projects where this is the case. But it’s still nonsense. Anyone suggesting this is good project management practice is either selling you a bridge or seriously misinformed about how projects are managed.

Plans – the strategy for the successful completion of the project, and the schedule – the sequence of work needed to fulfill the strategy are subject to change for every imaginable reason.

PM Quote of the Day — Roald Amundsen

Adventure is just bad planning.”

I’ve found that the amount of adventure in a project is inversely proportional to the amount of proper planning that went into — and continued throughout — that project.  Glen hits that point (here) when he uses the 5 P’s — a long-ago Scoutmaster (a USMC sergeant) introduced them more saltily as the 6 P’s — to frame a discussion of emergence in project requirements. 

In his own way, Sergeant Martinez made emergence very clear to we tenderfeet many years ago.  When we whined about having to learn how to prevent and fix blisters, to pack correctly, to read a map, etc., he asked those very same “If -> What” questions Glen mentioned:

  • If you get blisters, what will you do (without knowing how to prevent and fix)?
  • If if rains, what will you do (without a poncho)?
  • If you get off the trail, what do you need to to get back on it (without a map and knowing how to reach it)?

When we protested that we weren’t Marines he noted — after advising us that under no circumstances would the Corps want us anyway — that it was more important for inexperienced hikers to plan so that we didn’t get into trouble.  As he went on to note, on our hikes we were looking to have fun, learn a bit of woodscraft (actually “desert craft”), and otherwise enjoy our encounter with nature.  Fending for our health and lives wasn’t one of our hikes’ requirements…

Changing from a “work” to “deliverable” mindset

Glen Alleman has been a roll at Herding Cats, provoking some excellent back-and-forth in recent posts and comment threads.  His post (here) on Deliverables Based Planning (which is a service mark of his firm, I believe) prompted some knowing nods on my part.  As Glen notes in a comment:

You cannot believe…or maybe you can…how uncomfortable this makes people. They want to plan tasks! They want to track tasks! They want to be in control! (Deliverables are just a detail to be de-scoped when necessary).

We have passed through this vale of tears ourselves.  Since I’m on vacation and feeling particularly lazy, I’ll simply cut-and-paste from my own comment (with a few edits for clarity):

[T[he mindset change from simply planning "work" and "effort" to focusing on well-defined deliverables has been tough.  However, once we got through driving that change, we found few problems making most SAP project deliverables "tangible or verifiable."

This approach is especially effective when looking at the solution itself — most ERP-type deliverables should reflect enabling the execution of customer business processes (and the outcomes and benefits that ensue). This definition has proven quite tangible (the execution of enabled processes themselves) and verifiable (tests of the increasingly complex models of the processes, e.g., unit, string, integrated, business simulation tests).  Decently contructed tests should confirm whether or not the realized solution conforms to requirements. Furthermore, one can track the outcomes from these deliverables and trace the benefits — realized vs. expected. 

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”. 

Squaring up the PMBOK Guide and Agile

Glen Alleman shoots down some of the common misconceptions about the relationship between the PMBOK Guide and agile principles (here).  As regular readers know, I’m sympathetic to agile approaches, I’ve found them very powerful in the right project context, and I push to incorporate agile principles further into our own content. 

Of course, if I commented on Glen’s post itself, I’d be writing “ditto” or “I agree” a lot, so I’m just going to add on a bit:

  • While many agile advocates over-read the PMBOK Guide, the guide did imply a waterfall approach, especially in earlier editions (Chapter 2).  I can understand the confusion or over-reading.
  • The pending 4th edition does have a more sophisticated treatment of project life cycles and explicitly addresses iterative relationships among project phases.  It is hardly sufficient, but it is heading the right direction.
  • PMI itself is quite eager to engage agile advocates for future editions (or extensions) of the PMBOK Guide.  Several Global Corporate Council members were approached about how and whom to engage in the agile (or agile-savvy) community.
  • My take is that creating an Agile extension to the PMBOK Guide would be the best initial approach.  If nothing else, integrating agile-oriented PMs into the standard-setting process should be easier in an extension project.

Get every new post delivered to your Inbox.

Join 2,518 other followers

%d bloggers like this: