Our relocation project — capabilities vs. specs

As we planned our relocation, we started to search for houses using a set of “features and functions” that closely matched our current house. They were all pretty typical specs: bedrooms, baths, square feet, lot size, schools, age of house, etc.

This approach was useful when narrowing neighborhoods, but they didn’t surface the house we ended up choosing here in Evansville. The house we chose fulfilled the capabilities we wanted from our new house, even though it didn’t exactly match the specs we used to benchmark houses.

For example, our new house’s lot is about half the size of our old lot. However, it does give us the “lot-driven” capabilities that we require — privacy (house faces into a small cul de sac and has nice mature trees around it) and a large, fenced yard space — even though it didn’t match some key yard requirements we thought we had.

For me, it was a useful reminder not to confuse the capabilities one expects from a project with product/solution specifications. In this case, what appeared to be a clear-cut, “must have” requirement of “lot must be over x square feet” would have been better expressed as “lot must be private and have a large, dog-friendly fenced area.”

More importantly, the square footage specification was just that, a specification, not the requirement or capability itself. Specs must serve the capability, not vice versa.

Goals and the limits of self-organization

Thought-provoking post by Jurgen Appelo on the teleology of software projects (post here, check the perceptive comments too).  More properly, he points out that projects do not have a goal in and of themselves.  In his words, they don’t have intrinsic goals (other than self-preservation).

For me, this insight points to the limits of self-organization in initiatives.   IMO, without some degree of design — or extrinsic goals — a self-organized system (or pieces of that system) can get off the rails.  There is a tremendous amount of power in emergent-friendly systems — that’s what social media is all about.   For example, what emerges from Wikipedia is clearly emergent, but it has a explicit goal and with an extrinsic design model:

Wikipedia’s purpose is to act as an encyclopedia, a comprehensive written compendium that contains information on all branches of knowledge. 

Finding the proper balance between design and emergence is a fascinating topic.  In fact, my take is that this topic is the subtext of many of the arguments among methodology adherents — waterfall vs. agile. 

I’m always a bit leery of purist arguments.  In fact, I have a syncretist’s instinct to “square the circle”.  Perhaps what I’m looking for is something like Deng Xiaoping’s modifications to traditional Marxist dogma…   How about “Waterfall with Agile Characteristics”?

Will the Triple Constraint become the Project Diamond?

Craig Brown shares his experience (here) using a project diamond instead of the triple constraint (a.k.a., the Iron Triangle).  I was wondering whether someone would do like this… I’ve seen quality represented as a “Q” in the middle of the triangle or as an area “under” the triangle. 

I’ll have to think some more about how to use it.   I like the concept in theory, but I’m not sure how well the prioritization exercise Craig describes would work in practice.

BI, Deliverables, and Change Control

This post may court the Business Week curse, but I’m highlighting this story on BI and the recession (here) as the jumping off point for a couple of observations.  Rob T.’s comment in the piece (sorry, but I can’t link directly) notes that:

Unlike ERP, BI can be implemented step-wise, first in targeted, strategic areas, and then using a broad brush once it’s value has been proven. A wise strategy for this economy is to start small, pick a problem or area where a quick win is possible and attack it with a 60-90 day effort.

I mentioned this opportunity for short, focused projects in my WSJ interview.  These short cycle times and the nature of BI work pose problems for traditional ERP change control and deliverables definition. 

For example. what exactly is “done” on a BI project?  The traditional ERP definition of deliverables — focused on processes that deliver tangible, measureable outcomes (e.g., Order to Cash, Purchase to Pay, Hire to Retire) — doesn’t work well for BI.  Typically, reporting projects focused on # of reports, explicitly defined.  Also, in analytics projects those reports or queries often spark more ideas for how data can be cross-tabbed, projected, etc.  Do you always want to be presenting a change orders for new reports?

What has worked for you when defining deliverables and change control for BI initiatives?  Now if you’ve read this blog for a while, then you can guess that I’m in tune attacking these issues with a capabilities-focused approach to deliverables.  This approach points one in the right direction when defining what done looks like.  However, many PMs find it hard to grok the requirements and required capabilities of analytics-savvy stakeholders and consultants.

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?

More on saying “no” to customers, stakeholders, etc.

Pawel Brodzinski had a good comment (here) on my post about saying “no” the right way (here), which links to his post laying out his full perspective on the customer is always right principle.  I replied to his comment — agreeing with the principle, but cautioning on its application — which I’ve posted below:

Sometimes it is about saying no — or as the Japanese say “Yes, but.” There are times when we don’t take business, especially when we are being “forced” to do so. But if we aren’t taking their money, is that customer really a customer? IMO, no, at least not for that topic.

Of course, I agree that the customer is always right — which makes it critical to be choosy about one’s customers. But the application of that principle is tricky. PMs who allow scope creep to happen on their projects often justify it with a customer service rationale — “the users asked us to build it.” But are the users really the customer of the project? Aren’t the executives who chartered the project and the company they represent the customer? Too many IT staff and PMs are very confused about who is the “real” customer.

Saying “No” the right way

A colleague of mine, Schalk Klee, has a couple of posts of interest (Schalk’s blog is here).  I had forgotten to link to his original post on saying “No” as a PM (here), so his follow up post on when and how to say “No” (here) was an appreciated reminder.  Schalk highlights the balance that must be struck:

We all know that good scope management and customer focus are both critical success factors for value adding projects and in a professional service environment there is always the sales focus as well.  How do I balance this?

This is where I believe the art of making a deal comes into play.  This is a skill that a “good” project manager has to develop.  How do I give my client what they want without putting myself into a worse position?  Creative thinking, negotiation tactics and customer focus all need to be combined. 

Deal-making and negotiation skills are not emphasized enough in most PM career paths; frankly, I could stand brushing up on them myself!

All deliverables should be created equal

OK, that title isn’t exactly what this post is about, but I couldn’t resist the echo of the U.S. Declaration of Independence.  When I posted on promoting a deliverables-oriented mindset a few weeks ago (here), I started a draft post about project deliverables that don’t get held to the same standard as most product-related deliverables. 

The first group that came to mind were supporting deliverables: training, [added 9 Dec for clarity] organizational change management, etc.   While such deliverables may be tangible, validating the effectiveness of such deliverables is more problematic.  At least in my experience, the tendency in both cases is to focus on production measures (e.g., classes delivered, content uploaded/downloaded) or soft measures such as customer or training satisfaction.

We wouldn’t accept such fuzzy success measures for our solution deliverables, would we?  Have you all see better ways to measure and ensure the effectiveness of such enabling deliverables?  I have a few ideas and experiences, but I’d like to hear from you all first.

PM Quote of the Day — Pauline Kael

[T]he critic is the only independent source of information. The rest is advertising.

This quote came to mind as we’ve been going through an internal program’s requirements.  One of my colleagues regularly refers to, and insists on, using the “Four Eyes” principle.  In other words, one should always involve a second set of eyes to verify and validate work product.  If the project team is the only arbiter of progress

Too often, the four eyes principle often only gets honored in quality control — e.g., during post-build testing processes.  As my colleague’s insistence suggests, we find that an independent opinion is most valuable early in an initiative.  For example, wouldn’t it be useful to have an independent validation during planning that the requirements and deliverables really represent (and will make real) the capabilites the project or program is intended to put in place? 

It is tough enough to re-work a deliverable that doesn’t conform to requirements.  It is worse to have to re-build a deliverable that had conformed to requirements, but find that those requirements were never valid in the first place.

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.