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.

Continue reading

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!

Follow

Get every new post delivered to your Inbox.

Join 1,510 other followers

%d bloggers like this: