Archive for Project management

How to be a bad/good productmanager (and let RUP help you)

How To Be A Good Product Manager is a blog written by Jeff Lash that provides regular tips on good product management practices. While it focuses more on managing technical and online products, most of the concepts are appropriate for broader product management purposes.

I especially like the format of the posts, which follow the format:

If you want to be a bad productmanager, <follow some things you should not do>

If you want to be a good productmanager, keep reading ->

I was attracted to this site by the post stating Track customer requests appropriately and gave some RUP-related advice there: use your problem statement and product-position statement as tools for deciding which customer requests to include in your next release.


Leave a Comment

Continuously mowing better at Toyota

Toyota turned into a lawn mower 

In a fine article on “The Toyota way”, Howard Artrip, a Toyota manager in the assembly area examplifies his habit of constant improvement:

“When I’m mowing the grass, I’m thinking about the best way to do it. I’m trying different turns to see if I can do it faster.”

This constant drive to do things better and smarter is what distinguishes the best workers at the best companies.

Constant improvement is what happens when being on level 5 of CMMI.  Reaching level 5 means you must pass levels 2, 3 and 4. For all of these levels CMMI sets specific goals, and that seems to differ from the Toyota way.

As John Shook (“a widely regarded consultant on how to use Toyota’s ideas at other companies”) states in the article, “… Managers keep trying to make their management objectives. They’re moving forward, they’re improving, and they’re looking for a plateau. As long as you’re looking for that plateau,it seems like a constant struggle. It’s difficult. If you’re looking for a plateau, you’re going to be frustrated. There is no ‘solution.'”

“Once you realize that it’s the process itself–that you’re not seeking a plateau–you can relax. Doing the task and doing the task better become one and the same thing,” Shook says. “This is what it means to come to work.”

Leave a Comment

Early overtime == later project completion

Crossing the desertJohanna Rothman wrote about avoiding the “Crossing the desert syndrome” some years ago.

“A project team focuses on an interim milestone, works like the devil to meet that milestone. They meet the milestone, look up, and realize they’re not at the end of the project–they still have to finish the darn thing. They’re living the Crossing the Desert syndrome”

Recently she gave advice on how to recover from the syndrome.

At Tyner Blain, Scott gives advice on how to prevent from hitting the syndrome: 

  • Improved estimation of tasks
  • Realistic effort allocation
  • Writing verifiable requirements
  • Managing smaller work chunks
  • Feedback into the estimation cycle
  • Better communication of release content

As I read his advice I thought: “yes I agree that’s good advice, but somehow good advice is seldomly followed”.

 BTW: Patrick van Lee, a relative from my wife,  rides the Dakar race on an Aprilia motorbike

Comments (1)

Outsourcing: from assembly line to extended team


Recently I became interested in outsourcing. Partly because we addressed the subject in reaching CMMI level 2, partly because I recently read the book “The World is Flat” in which “Thomas L. Friedman believes the world is flat in the sense that the competitive playing fields between industrial and emerging market countries are leveling. Friedman recounts many examples in which companies in India and China are becoming part of large global complex supply chains that extend across oceans …” (from Wikipedia).

In Managing outsourced teams. Balancing innovation with predictability. two different approaches to create a remote engineering organization:

  • Assembly line (requirements are sent overseas to be built there as specified; prerequisite is that the requirements are really good and stable)
  • Extended team (requirements are sent overseas and interpreted, a design or prototype will be created overseas and approved by the main office, emphasizing on collaboration).

Based on their experience the authors suggest that the best way to go about this problem is to start on the Assembly line “mode” and to transition to the “Extended team” mode as soon as you feel comfortable to do so.

hidden costsI think that’s a sound suggestion! Beware that on both approaches, there are lots of hidden costs when outsourcing.  

Leave a Comment

RUP related

To catch up with newer posts, here are some subjects that were on my to do list, all having to do with RUP:

Project Management with the IBM Rational Unified Process – Lessons from the Trenches by R. Dennis Gibbs.  Should be especially interesting if you are involved in managing an outsourced project with RUP.

Extending RUP with the Portfolio Management Discipline by Scott W. Ambler, John Nalbone, and Michael Vizdos (the guys from EUP).

Integrating the Rational Unified Process with Managing Successful Programmes, by Russel Norlund.

Leave a Comment

Handling feature-creep on your NEXT RELEASE

Next release ...In an interesting post on changing the way his company (37signals) is managing the naming of new versions, David explains they left the habit of numbering from version 2.1 to 2.2, and instead name the versions after the biggest common feature the new version delivers.

So if the next version is all about improved security, the release is simply called the “improved security release”.

This clear naming convention helps David to decide what’s in the next release, and what’s not.

The post was noticed at Tyner Blain, who devoted an enthousiastic post on the subject.

Actually, the convention fits nicely in the way releases should be handled within RUP. For every release a problem statement and a product position statement are developed AND agreed upon between all stakeholders of the project.

The problem statement is a solution-neutral summary of the stakeholders’ shared understanding of the problem to be solved.
The product position statement is the “mission statement” for the system to be built (the solution). The product position statement is a vehicle for communicating a brief definition of the system to all stakeholders (definitions from safari).

The problem statement and the product position statement are excellent tools to use in the CCB  (Change & Control Board) who decides on including or excluding new features in the (next) release. Both statements are documented in the RUP Vision document.

If you have a hard time defining these statements, you will definitely have a hard time with scope-creep. Now you see why!

Comments (2)

Patterns for Daily Stand-up Meetings

On one of my previous projects we organized daily stand-up meetings, where everybody gathered together at 09:00. In turn everybody said what they did yesterday, what the planned to do today and whether anything was hindering them to make progress.

After a while, it appeared that some people had something to say every day (and some had a lot to say) and others never had anything interesting to share. Somehow, the stand-up meeting was not working.

Jason Yip published a comprehensive post about stand-up meetings, and discusses a number of “patterns” used. Perhaps we should have looked into the “Pigs-and-Chickens” pattern before…

James ShoreMore wrote a chapter on stand-up meetings in his book The Art of Agile Development. Some chapters of the book are available as preview

Leave a Comment

Older Posts »