Tuesday, March 10, 2009
I was thinking about the massive projects that the world has seen, like the Pyramids, great Dams, Bridges, Skyscrapers and Railways, or well-designed and -architected cities in general, and wondering: Are these things we marvel at, built on great inequities? Inequities that people of certain demographics cannot even imagine (thinking about myself as a white, male, middle-class American).
It's not comfortable to think about, but would such marvels even exist if there were not the exploited and the exploiters? Can this said to have been even necessary for technical progress?
Food for thought.
Monday, March 09, 2009
Monday, March 02, 2009
A friend mentioned that she understands better "why Japanese are like they are", after having been on a weekend bus tour to Mt. Fuji. I've been on Japanese bus tours before, but it never really dawned on me that they could be a window on the soul of the Japanese, but I suppose they are, in a way. I've always been against them, but occasionally bow to pressure from the higher authorities at my house, like my wife and daughters, and go on a bus tour.
On projects I've groused with other PMs that people here expect everything to be presented on a silver platter. And by people, I mostly mean Japanese people, who are the users in 99% of the cases where I'm managing projects. It has been difficult to explain why I would not write out every step for every action by users, and I think the bus tour is at fault! Consider the careful service you get on a bus tour:
- Everything laid out in great detail with to-the-minute scheduling of every stop on the tour. Now we're using the bathroom, now we're buying souvenirs.
- A tour guide with a little flag to lead you around the site, in case you can't read the detailed map you've been given. This is a famous sight, is it not?
- Continual announcements about what's next and what just happened, as well as the rules you'll need to follow. Just in case you did not get it from the detailed itinerary.
- Big signs saying how many minutes you have at the particular stop, again, in case you did not understand the repeated announcements.
Westerners certainly have a different approach to things of course, and generally take a more independent, less supervised approach. So one could either feel a bus tour in Japan is either incredibly well put together, or incredibly overbearing. A taxi driver I mentioned this to said that Japanese expect this type of treatment, because their mothers tell them what to do at every turn.
Maybe the PM title stands more for "Project Mother", in Japan. I suppose I should just get used to it, after such a long stay here.
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.