Continue in 2 seconds

Project Management Basics

  • April 01 2004, 1:00am EST

While preparing last month's column, I started to write about the importance of understanding business processes when defining system requirements. 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? I wrote a column on customer data management instead.

However, 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. Then I decided, what the heck, this is worth sharing with the rest of you because the best advice I could give had nothing to do with formal project management theories and everything to do with common sense.

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 enables you to 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 is 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 though 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. However, 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. However, 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 more difficult 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 steps 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. However, 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. Actually, it's not really embarrassing: effective project management is more difficult than it seems.

Projects are more about people than technology. You've heard this a million times, but it's true. It really comes back to the focus on business process -- you can't just install new systems and hope they get adopted. 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.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access