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

methodologyscaling

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…

Follow

Get every new post delivered to your Inbox.

Join 1,510 other followers

%d bloggers like this: