Once all the planning is done, the project approved, the specifications set, then Coke and pizza come out and, in a dark room, developers get to work.
Good management, or “riding chaos” as some might put it, plus teamwork, allows projects to finish on time, on budget and with psyches intact. This is potentially the most accident-prone phase of the project.
Accident prone because this is the phase when the team really must pull together and work solidly for several weeks or months at a time, heads down, brows furrowed. If there were personality conflicts amongst your programmers you didn’t know about before, as a project manager you’re going to find out now, during the development phase.
“Personality conflicts are the biggest problem in a project team,” said Jacques Giraud of Toronto’s Corelan Communications. “I had an instance where one of the junior programmers threw an ashtray at the senior programmer and started a fist fight. We fired the junior programmer (after he bit the crap out of the senior programmer) and that improved morale so much the project came in earlier.”
This is an extreme example but indicative nonetheless of the terrain project managers navigate when managing people. It’s what project management guru Jim McCarthy means when he talks about the psychological tapestry of project management. No big breakthrough here; basically, if your team isn’t communicating or if your people are demoralized, you’re going to have a real mess.
Rob Lavigne of Akanda Innovations sees personality conflicts as a real project killer. He seeks first to hire staff members who fit into Akanda’s corporate culture. “I will often hire for office-cultural match over someone with technical superiority who may cause ripples with my existing staff.”
Of course, daily frustrations do arise, and Lavigne often turns to the project manager’s preferred team building and tension relieving tool from ID Software. Yes, Quake. “Nothing beats a fun and relaxed environment that allows programmers to break from the frustrations of the project,” Lavigne said. “We will often have a Quake night to relieve the stress incurred by daily frustrations.”
But Lavigne also understands that the project itself must be interesting to his developers. Ken Zubricki of Nortel Networks keeps his team members motivated and excited by trying to maintain the following three points:
1) Ensure coders are learning something new and know what role they play.
2) Ensure the project is a priority and important to our customer’s success.
3) Ensure programmers are getting some career development out of the project.
Nothing demoralizes like that descent into Dilbert’s world. When the project requirements seem to be adrift or the project itself is not challenging or doesn’t seem to have a real purpose, the whole team — including the project manager — starts to feel a strange sense of hopelessness. When this happens, sometimes over-managing can be the worst course of action.
Larry Schoenfeld of eWatch (a subsidiary of WavePhore) has a mortal fear of the Dilbert environment. He said he works at maintaining his team’s enthusiasm “by making sure they don’t mistake me for Dilbert’s pointy-haired boss. Nothing slows down developers more and makes them more cynical than a befuddled boss. You would like to think that this industry is past that stage of its development, but there are still some managers out there who want to throw 100 people on a project to bring a 100-week schedule down to one week. I can only offer them my prayers.”
A solidly motivated team can work wonders. John Kvasnic, of Toronto’s Empower Systems, uses doses of Quake on a regular basis and keeps his developers motivated by constantly upgrading their skills with courseware.
He claims the payoff is huge. “If we keep our programmers well motivated, we’re in much better shape to deal with some of the issues we unearth during our risk analysis process. It gives us some flexibility, especially if we’re ahead of schedule, to deal with things like scope creep.”
Scope creep. It’s like chasing the horizon. Your customer changes requirements so often, it can be impossible to tell when the project might end.
Giraud has plenty of experience with this phenomenon and sees it as a way not only to demoralize his staff, but also to wind up with an unhappy customer.
“I was PM on a system to allow for the transfer of reps between dealers and brokers,” he recalls. “We would have meetings twice a month to determine functionality. Problem was it was a constantly changing committee of people, each with their own agendas. We would implement a feature one week, and then it would get taken out the next week. The same feature was added and removed three times. Net result — the system cost close to $300,000 rather than $50,000. And nobody was ever happy with it.”
Giraud has four recommendations on scope creep, and how to manage a client with a fuzzy focus during the development phase.
1) For time and materials projects, try to be as accommodating as possible while advising the client of the schedule and cost ramifications.
2) For fixed price projects, try to fit in small requests as long as it doesn’t become a habit. If it does, add it to the feature queue for a future release, and turn into a schedule fascist.
3) On highly competitive fixed price projects, you have to be a schedule fascist. A lot of the margin has been lost to get the business, so change has to be tracked and monitored very closely.
4) If the rate of change becomes ridiculous, try and get the client to close the current fixed price contract, then start a new billing docket. This has a sobering effect on most clients.
In the end, Giraud believes it’s important to “be fair and reasonable about what you ask the programmers to do. If they have to work overtime, pay for food and call during the overtime to make sure they are okay. If there is customer-requested overtime, make sure the developers get time and a half for their work. Review their work on a regular basis and give them credit where credit is due. Keep them focused on building the bare minimum to get the job done. Find out who works best together and try to keep them working together on items they like to do.”
And what about Quake? Giraud sees it as an important team-builder. “Play games and drink beer at least once a week to relax and just talk about the last week.”
Next Time: Demonstrating the effectiveness of your product.
Martin is a project manager at a Toronto communications firm. He can be reached at jasonjmartin@geocities.com.
