Velociteach PM Poster - Observations

Velociteach created this excellent Project Management-related poster, talking about the gap between what users say they want, what they really want, what's sold, what's delivered, what's paid for, and what's supported. Are things really this bad? From experience on many a large project I would say they are.

Some Current Problems in Projects Today

This poster hammers home the concept that stated requirements have to be well-linked to what's delivered, a concept that has been emphasized for quite some time in software development camps as a reaction to "waterfall" type project management. If you're not familiar, waterfall is a "command-and-control" concept of PM where everyone marches lock step through phases, changing phases when the documents are signed off. That might sound comfortable to people who are not detail-oriented enough to really understand what is going on, but the reality is always messier. Other approaches such as or stemming from "Agile" or "Lean" software development, help keep the focus on what's valuable to the customer, and avoid meaningless rounds of documentation and signoff. Note, I did not say those approaches advocate not documenting at all, because that does not appear to be the case.

I was the Japan-based PM for an ERP implementation, where the head of the PMO at my client generally encouraged the use of more Agile methods. We never talked about Agile and what it meant per se, but recently studying Agile for how it might help me manage non-software development projects or general projects, I can see similarities between what's in the Agile Manifesto and Agile Principles, to what we actually did on the project.

One thing that we did which was rather too "waterfall" however, was an attempt to document all the user requirements up front, in a huge list. This quickly got unmanageable partly because we were trying to do requirements this way, with users inexperienced in ERP implementations, and partly because we were using email as a collaboration tool, which was a mistake as well. Thinking about that, users would have had a terrible time trying to remember what they said, in requirements meetings many months back, in specification review sessions. Adding to that the need for translation and interpretation services, it's a wonder we went live as successfully as we did. An attestation to having the same developers and coordinators involved the whole way through, and just general tenacity, if you ask me.

What to Do About It

In summary, my current feeling about what to do is the following:

• Though Email has obvious benefits and applications, attempting to collaborate in Email is not the right approach or, dare I say, any project. Instead, use a system like TargetProcess, LiquidPlanner, Unfuddle, MyIntervals or even BaseCamp.
• Use a V-shaped project process, to link user requirements to user acceptance tests, designs to design validations and so on, so that there is a check and balance in your process. Make it easy for users to see the link between what they asked for, and what was done in the end.
• Poorly-done Agile is just as ineffective as Waterfall, so if you are going to implement different methods, make sure they fit and that you do it skillfully so the whole entity supports it. Don't use Agile as an excuse to be lazy. In fact, Agile requires even more discipline in the team.

The jury is still out for me what the "best" method is and what the best collaboration software is, but I have taken my time to understand methods besides waterfall, and am beginning to apply them in practice. I will post here about my experiences from time to time. I hope you Enjoy this.