Posted by Robert Merrill on March 2, 2010 under Estimation, Project Set-Up, Software-Intensive Businesses | 
Q: Why were they late for the meeting?
A: They didn’t leave soon enough.
But…they got stopped by a train, and they remembered that they needed to pick up a loaf of bread, and…they have a slow car!
Details like speed limits and the police aside, what do the car, and the bread, and the train have to do with it? The trip took 25 minutes, five of it spent waiting for the train, and five of it in the convenience store, and fifteen of it driving. They left 20 minutes before the meeting, and they were five minutes late.
Well, they didn’t plan on the train or the bread.
Do they ever plan on the train or the bread? Read more of this article »
Posted by Robert Merrill on January 27, 2009 under Project Set-Up |
In a podcast interview with ZDNet “IT Project Failures” columnist Michael Krigsman, Bruce Maas, CIO of the University of Wisconsin—Milwaukee sees the roots of success or failure early in project initiation. In his experience, successful project set-up establishes:
- Relationships
- Shared vocabulary
- Shared definition of success
For going on ten years, I’ve specialized in project set-up. It’s part business and requirements analysis, part technical architecture, and part project management, specifically estimation, and I have to say, Amen, Bruce!
Projects in which the business and IT folks fundamentally get along and respect each other can survive the inevitable surprises–requirements no one thought of, technologies that don’t play well with others, and estimates that were, well, estimates.
People can’t get along and respect one another unless they can communicate, and that takes a shared vocabulary. Bruce Maas recommends the IIBA vocabulary as being relatively simple to learn. It’s more of a meta-vocabulary, establishing common understanding of words like “requirement,” that then give you a language to talk about the actual problem. There are alternatives to the IIBA way, but I agree that it’s better than no shared vocabulary at all.
With positive regard for each other and a way to communicate, the suits and the geeks then have a fighting chance of agreeing on a definition of success, not just for themselves as suits and geeks but for the project they’re taking on, together.
In his role as CIO, Bruce Maas has proactively worked to build relationships (through social events) and shared vocabulary (by bringing in IIBA training), apart from any specific project. Not typical CIO stuff.
Give it a listen. The interview is less than eight minutes long.
Posted by Robert Merrill on September 30, 2008 under Project Set-Up |
I keep getting a trickle of traffic from this post I made on an InfoQ forum back in July, so I really ought to write more on the topic (I finally did). But for now, here’s the comment that continues to spark interest.
Maybe outsiders see the lack of OUTWARD-FACING metrics, that can be compared across projects or even industry-wide. Agile thought leaders seem metrics-averse, maybe out of reaction to the way metrics have been used (and abused) in the past. As I see it, the basic four, productivity (X/effort), velocity (X/time), quality (defect/X), and value (benefit/X) still apply, and within a project, agile teams track and respond to them, in their own effective ways (measured velocity, continuous integration and automated tests, planning game). But when you need to compare projects, you need a more portable X, or what I call “an ounce of software.”
I used to do project set-up for a contracting shop that used agile methods. We needed a decent estimate before we even got the chance to establish a velocity. That estimate needed to be clearly traceable to the initial requirements, to help the client think “scope-to-budget” from the start. The estimate also needed to be tied to actual results on other projects, so it couldn’t be pressured down. Based on these requirements, I introduced Function Points. Usually dismissed with a sniff by agilists, they did just what we needed, and didn’t interfere with people and interactions at all. They also helped our initial story development by revealing gaps and implied stories
You can read the complete thread, “Agile Measurement – A Missing Practice” on InfoQ.