Posted on July 12, 2009 by Paul Ritchie
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.
Filed under: Requirements Management, Scope Management | Tagged: capabilities, house hunting, relocation, requirements, specifications | 3 Comments »
Posted on March 4, 2009 by Paul Ritchie
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.
Filed under: Project Management, Requirements Management, SAP, Scope Management | Tagged: Analytics, Business Intelligence, Business Objects, change control, change control board, deliverables | Leave a comment »
Posted on February 26, 2009 by Paul Ritchie
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?
Filed under: Communications, Project Management, Requirements Management, Scope Management, Stakeholder management | Tagged: deliverables, Glen Alleman, Herding Cats, WBS, work packages | 1 Comment »
Posted on January 7, 2009 by Paul Ritchie
“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…
Filed under: Portfolio Management, Program Management, Project Management, Requirements Management | Tagged: 5 P's, Boy Scouts, Emergence, Glen Alleman, Herding Cats, hiking, Marines, PM Quote of the Day, Roald Amundsen | 1 Comment »
Posted on December 2, 2008 by Paul Ritchie
[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.
Filed under: Program Management, Project Management, Quality Management, Requirements Management, Scope Management | Tagged: Four Eyes Principle, Pauline Kael, PM Quote of the Day, Quality Assurance, Quality Control | 1 Comment »
Posted on November 26, 2008 by Paul Ritchie
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.
Filed under: Business Case, Program Management, Project Management, Requirements Management, Scope Management | Tagged: deliverables, Glen Alleman, Herding Cats, WBS | 3 Comments »
Posted on November 23, 2008 by Paul Ritchie
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”.
Filed under: IT special interests, Program Management, Project Management, Project Success Factors, Requirements Management, Scope Management, Troubled Projects | Tagged: change control board, executive buy-in, executive sponsor, Glen Alleman, Herding Cats | Leave a comment »