It’s a minefield. And a few mantras guide successful project managers through it.
For Larry Schoenfeld of eWatch! (now part of WavePhore), it’s “Listen, listen, listen.”
For Ken Zubricki of Nortel Networks, it’s “Requirements, requirements, requirements.”
In this, the second of a series of articles about North American project managers and their jobs, we’re looking at the first phase of project development. This definition phase is often called the requirements phase.
And it can be a minefield.
Zubricki said, “Too often end-users (customers) know what they want but do not actually explain the problem that needs to be solved. As a result, we may develop what was requested, but it may not be what customers need.”
That’s why God invented requirements documents. But what if your client doesn’t see the value in clearly defining the project?
Jacques Giraud, senior project manager at Toronto’s Corelan Communications, explains that often clients may not understand why, when they’re paying good money, programmers spend all this time talking and writing documents instead of programming.
“Clients often feel that programmers not coding are a waste of money,” he said. “We tell our clients that the front-end of a project is the single most important piece as it sets the tone and direction for the rest of the project. Brilliant programmers can’t make up for missing analysis or not understanding the client’s problem.”
Often the smoothest project definitions occur when IT departments clearly set out their own objectives. However, when a project originates from a marketing department rather than IT, the capability for miscommunication is quite high. Giraud notes that salespeople and marketers, although “just as important as programmers, view the world differently.”
This can manifest itself in extremely fuzzy requirements, or unrealistic expectations, or an ungainly understanding of the development process. The grey areas where sales and marketing flourish are often at odds with the black and white world of IT.
Zubricki proposes some reconnaissance. “I worked for a couple of years in sales prior to joining Nortel Networks and I think everyone in development should spend some time in this area.”
Since sales and marketing may often be the ones setting the agenda, better understand what language they’re speaking.
Schoenfeld echoes the call for mutual understanding by suggesting PMs always partner with their clients. “If you and your partner (customer) recognize your relative strengths and weaknesses, you are in good shape to proceed.”
A large part of this partnering approach involves educating the client or end-user.
“It’s not that important that a client understand our process in great detail,” explains Giraud, “but they must be clearly focused on what they need from a business point of view. If the client doesn’t understand what they want and are not willing to pay for the development of detailed requirements, we don’t do business with them.”
There are some alternatives, of course. One sets the development team coding and going back and forth with the client until the client is satisfied. This method of evolutionary prototyping can lead to longer production schedules and bloated budgets, yet often results in great products. But even if you go this route, you need to start somewhere. Start with a mutual understanding of what is to be accomplished.
Robert Lavigne of Akanda Innovations sees communication and client handling as critical. “The creation of a communication layer at the beginning of the project is the most important task of the project and account managers.”
The only way to plan is with clear requirements and a development model that is appropriate to the requirements and the client. Said Giraud: “There is no single methodology that works in all cases, so we pick and choose the most appropriate given the client, project and timeline.”
Schoenfeld’s approach emphasizes communication and an ability to be flexible. “I explain to my client the process that I like to use in general, and how I apply it to their specific situation,” he said. “I don’t like to emphasize process at the start of the project only — process is an ongoing discussion that is affected by the real world. I worked for one company that gave a textbook presentation of process at the start of the process that would knock your socks off — glamour slides, the whole works.
“One week into the project, chaos reigned, and of course there was no process to deal with it.”
A minefield.
Next Time: designing the project.
Martin is a project manager at a Toronto communications firm. He can be reached at jasonjmartin@geocities.com.