coneblog

In the interest of highlighting a technique that we all probably use, I’ll share an effective PM strategy – the “Oh Crap” meeting. An “Oh Crap” meeting can is an opportunity for the project team to identify problems, vent, and sometimes even confess.

In the course of most projects, there comes a time when the project has gotten off track. Sometimes this occurs early, when the scope or design had not closed, and it is obvious to all that the project is adrift.

Click to read more ...

A Zen Master’s quote got me thinking about Project Management.

In the past, I have been criticized for any number of project management misdeeds.  I’m told that I have a tendency to shoot from the hip, modify on the fly, and to Not Work the Plan.

Click to read more ...

Reflections on the possibilities and realities of the Software game, and the need to say No.

No is a useful word. In child rearing, it sets boundaries for the child. Boundaries that are desparately needed by a toddler who is trying to assert his independence in a huge scary world, and who needs you to set some protective barriers.

No is also valuable to the teenager, who needs to be protected from his or her own urges and needs, and who needs to know that you value her so highly that you will fight her to keep her safe.

And No is an essential component of a software product strategy. I read Susan Mernit’s Post on no  the other day, and was struck by her insightful comments.

As we all know, you can do anything with software, given enough time and money. But that’s the rub, isn’t it – we need to function in a time and resources bounded world. So we need to say No to everything in the universe of possibility in order to accomplish our small thing.

I typically rage against the No. In my passion to deliver great software to my customers, I want to give them features that they need. And I’m all too aware of the long slow delivery cycles, and the possibility of not getting another chance. I typically go the “make the pie bigger” route – looking for ways to improve productivity and/or cycle time to deliver more. Or to be smarter about prototyping and cycles so that the application delivered is its lapidary best. (characterized by an exactitude and extreme refinement that suggests gem cutting: a lapidary style; lapidary verse).

But, even I give way to the need to exclude in order to include, the need to say no. Susan cites some common reasons for this in product development:

• The project isn't something we have the resources to do right now--and it's not worth prioritizing over something else
• It's a nice to have, not a must have
• The level of effort and the return don't line up enough
• It's distracting from our core business objectives--for the year or the quarter
• It's overbuilding--we think it's neat, but customers won't notice
• It's too bleeding edge (this is a subset of overbuilding)--we love the idea but the novelty outweighs the business impact

These are all good reasons. In the face of cool features and impassioned supporters, it is hard to sort out. But sort we must, because we have to say no a hundred times for every yes.

In starting a new project, I try to identify the main risk – and structure the project accordingly. Most of the time though, it is the same risk.

Click to read more ...

Earlier this year I got an advanced lesson in listening – how to listen in order to be heard. I fancy myself a good listener, but I found that I had violated one of the cardinal rules of the speaking/listening dynamic.

Click to read more ...