Each week, project management veteran Tom Mochal provides valuable advice on planning and managing projects. He first describes a common problem scenario based on a real-life situation and then offers a solution using practical project management practices and techniques.
The last few projects that Chi-Ling managed had required little input from me, but she was a little less comfortable with her current project to create a collection and reporting application to show all company taxes paid on a worldwide basis. She came up to me at the snack machine and asked one more important question about how to approach the execution of this project.
“I am completing the end of the Project Definition document,” Chi began. “I’m struggling a little with how to execute the work. Normally, I’m comfortable with a traditional analysis/design/construct/test approach. However, I don’t know if that will work in this case.”
My general belief is that the traditional waterfall approach will work on all projects. It may not be the most efficient, but it should always be a potential method to get the work done. “Really!” I replied in a half-serious tone. “Why won’t that work on this project?”
“After talking to the client on a couple occasions, I don’t think they are going to be able to provide the detailed requirements we need,” Chi replied. “They have a vision for what they want, and it is very important, but they have not fleshed out the details of what information is needed.”
I opened the pack of crackers I was having for lunch. “Don’t start the project if you don’t think they can tell you what they want.”
“I don’t think the project should be delayed,” Chi said. “They have a great vision but not the details. I was wondering if this is a time for structuring the project using the Rapid Application Development approach.”
I tested Chi’s basic knowledge to make sure she had thought this through. “How will a RAD approach help you?”
“What I would like to do is work with them at a high level to build a set of online screens that will display tax reports,” Chi said. “I think that when they start to see some actual data and reports on the screen, they can describe what will be needed. They can then point us further in the right direction through another set of requirements. I think if we go around with them a couple times, we’ll get the requirements we need.”
Chi went on to explain that once they knew what information the client wanted to see, her team would start to determine what type of data to collect and where the information would come from.
“If we’re lucky, by the time we get through the third or fourth iteration, we should pretty much have the requirements and a working application at the same time,” Chi said.
I thought for a couple of seconds about what Chi was saying. “That might work,” I concluded. “The good news is that you’re thinking about all of this ahead of time.”
Part of a project’s planning process is to think through your project approach, in which you describe the type of project you’ll be executing, the major phases of the project, and any special techniques you’ll use. Examples of a development approach include waterfall, RAD, and Agile processes. Project managers tend to execute a project in the same way they executed previous projects. For example, if you have had success using a RAD approach, you may tend to do your next project using the RAD approach, without thinking about whether it’s the best approach given the characteristics of the project.
On some projects, you have options on your overall approach, any of which could work. On other projects, one approach may be better than another. For example, a development project that is heavily batch-oriented wouldn’t be a good candidate for a RAD approach, since RAD is best utilized when you have something visual to show the client.
Chi is consciously picking an approach based on some characteristics of the project. Although she’s more comfortable with a waterfall approach, she has chosen to use RAD techniques here because she has a heavily online solution, and she feels that the clients will be able to describe the business requirements better if they can see the solution a little at a time.
On another project that I was involved with, the project manager decided to use a RAD approach and built a series of solution iterations. On this project, the client needed to go through three iterations before they felt that they really understood what they were doing. It took another three iterations to get the solution right—six iterations in all. In the end-of-project meeting, the consensus opinion was that the project should have employed traditional waterfall techniques to force the client to really think through their business requirements before the team started design and coding.
The moral of this story is that project managers should understand that there are a variety of approaches to development projects. Don’t structure the project in a certain way just because that is the way you’re used to. Look instead at the characteristics of the project and pick the overall approach that best fits the circumstances.
Tom Mochal is president of TenStep, Inc., a project management consulting and training firm. Recently, he was Director of Internal Development at Geac, Inc., a major ERP software company. He’s worked for Coca-Cola, Eastman Kodak, and Cap Gemini Ernst & Young. Tom has developed a project management methodology called TenStep and an application support methodology called SupportStep.