Project Management Basics by David M. Raab DM Review April, 2004
While preparing last month’s column, I started to write a column about the importance of understanding business processes when defining system requirements. But then I reconsidered: other people have formal methodologies and even academic degrees in such areas; who am I to present my own ideas as if they matter? And you got an article on customer data management instead.
But not a week had passed before a former client called and described a current project he feared was headed for failure. The more I heard, the clearer it became that the project was indeed likely to go nowhere. After pondering how to diplomatically approach the client’s boss with an offer of assistance–without, of course, suggesting he had made any mistakes–I found myself writing a brief summary of project management advice based on 20-plus years in the trenches. And then I decided, what the heck, this is worth sharing with the rest of you. Because I realized the best advice I could give had nothing to do with formal project management theories, and everything to do with common sense.
So here goes.
focus first on business processes, not on systems. Business people think in terms of processes, and processes cut across systems. A business process such as signing up new customers, for example, might involve sales, customer service, accounting, and field support. Benefits used to justify projects are also organized more by process than by system. This means that business cases also start with a process-oriented analysis.
requirements flow from processes. After you define processes, you can identify the specific requirements the processes impose on individual systems. Benefits, which are simply the results of new or different processes, may impose additional requirements. Linking requirements to processes lets you make sure your requirements include all of your actual needs, rather than a superficial wish list developed through general discussions.
requirements must be detailed to be useful. It’s impossible to overstate the importance of requirements in a project. “Meeting requirements” is the definition of success: if you don’t have good requirements, you’ll never know whether you’ve succeeded, or even when you’re done. Yet we often see cursory requirements lists that look as if they were slapped together in a few moments–presumably on the theory that it was more important to get started on the real work of vendor research or system development. But without an advance understanding of requirement details, there is nothing to guide later decisions.
dependencies are not always obvious. For complicated projects, I often create a matrix showing which requirements are needed to support which processes or process enhancements. These requirements can include data sources and system functions. Putting together such a matrix is an excellent way to clarify project components and dependencies. It’s also fun (am I allowed to admit this?), like solving a puzzle, to find the sequence that gives the most value for the least investment. But, also like a puzzle, it’s not very interesting to look at once completed. Don’t be surprised if no one else cares to examine it closely.
communication is harder than anybody thinks. Just getting your team members to use a common vocabulary, have a shared view of basic processes and systems, agree on project objectives and identify success criteria are major steps toward success. These might evolve over time by themselves, but it’s best to address them directly at the start. Such discussions may feel like a waste of time to those impatient to get down to business, but a common understanding will make later project stages move much faster.
project management matters a lot. Like communication, this is just basic blocking and tackling–tracking schedules, issuing conference reports, following up on action items, publishing agendas, and so on. But it’s easy to overlook, particularly if there isn’t a dedicated project manager or formal project management process in place. It’s almost embarrassing to admit how much of the value provided by external consultants really boils down to performing these tasks correctly. But it’s not really embarrassing: project management is harder to do well than it seems.
projects are more about people than technology. You’ve heard this a million times but it’s still true. It really comes back to the focus on business process–you can’t just install new systems and hope they get adapted. Rather, you have to make sure the organization will make all the needed process changes. This is particularly important when the project involves operational workers, such as field agents and call center reps, rather than a handful of business intelligence analysts. Everyone knows this, but it’s still common to see projects that focus on system selection rather than the big picture.
Of course, there’s more to a successful project than managing the process correctly. But manage it poorly, and failure is virtually certain. Fortunately, this is an area in which a little common sense goes a long way.
