Introduction
A quick search for "Project Management" on Google yields 5,050,000 results; very few of them will tell you what you are looking for or what you need to know, and seemingly everyone wants you to attend a seminar or buy their latest book. Project management seems to have gained much ground in industry over the last decade or so, and countless consulting firms have popped up out of nowhere to capitalize on the trend, yet the details of the subject itself remain as elusive as the mechanics of magicians' tricks.
In light of our CP community's latest joint project efforts, I am writing a series of articles related to the theory and direct application of the principles and techniques of project management. My goal in this series of articles is twofold:
- To present project management in a straight-forward way such that you can begin to apply the principles and techniques to your projects today.
- To sharpen and enhance my skills and knowledge, by obtaining feedback from a community of experts.
This article presents the following topics:
- What is a project?
- Project management: Where Julliard meets MIT
- The project lifecycle
What is a project?
Generally, work is divided into two categories: on-going operations and projects. On-going operations are at the heart of most industries and entails day-to-day operations with no clear end in sight. Projects are events that happen only once and contain certain start and end dates. We in the software industry are usually involved in projects and probably aren't interested in the details of on-going operations, but it is fair to note that projects generally have a direct impact on these operations. A change (or desired change) in operations is most often the catalyst behind the project in the first place.
Why should you continue to read this article?
I can see it now: "I'm a software developer, why would I want to read about project management?", or "When I come to CodeProject, I want to see code, not this project management *&@#!", or even better: "This project won't compile under my version of VS.NET, can you help me?". Well, let me tell you why this is so important. There are two houses of software development. Jolt Cola sponsors one, while Serta is a proud sponsor of the other. If you haven't guessed, the first house is the "code-like-hell" house, while the other is the "follow-the-plan" house. We will get into the specifics of the software development process in another article, but for now we will focus on project management. Think of it as planning a trip to the grocery store versus planning a trip from Key West, Florida to Barrow, Alaska. Surely you can travel to the grocery store with minimal effort, but the greater trip requires a little more effort than merely checking the gas gauge. The moral of the story is that project management benefits everyone involved, whether you are the project manager or the proverbial "code monkey".
Project management: Where Julliard meets MIT
Project management is quite literally an art and a science. The science portion is obviously the most tangible aspect of the craft, built upon the technique and execution of the principles of project management. It is the art of leadership that people pay for. If you take the best member of an orchestra from every country and put them together in the same concert hall without a conductor and expect them to play a movement from one of Mozart's works, it would surely end up a disaster. No one would know how loud or soft to play and you would end up with a neutrally stable response at best. This analogy lends itself nicely to our CP projects doesn't it? We have excellent developers from all over the world, and we are joining together to produce a symphony of software. It is up to the project leads to be the conductor of their orchestra.
The art of leadership is not found in your genetic code. (Ok, well maybe some of it is, but this isn't an article on social psychology...) The point is that leaders aren't "born", they learn. Successful project management revolves (like any freely revolving body) about it's center of gravity, that of which is the project's vision. That vision can best be summarized in five distinct yet necessary parts.
Vision: Part I - Achieving consensus about the vision among members of the project team.
As a leader, it is the Project Manager's (PM) duty to study, listen, learn, and persuade the team to adopt the best solution. Many times the PM will be forced to make a decision without knowing all the variables needed to formulate an exact solution, and will need to rely on instinct and experience to make the best decision. This is where the art comes in. There is no exact science to visionary leadership, it is a skill that must be constantly honed and developed. No two projects are alike, yet the skills required to see them through to completion, never change.
Vision: Part II - Establishing the vision against which to measure progress.
As the PM, it is your duty to rab the project in every aspect and maintain an accurate account of progress in every respect. However, the art involved in this is that, you need to do so without anyone ever knowing you're even there. Now that doesn't mean be lazy and status people once a week, that means know where everyone stands with respect to the vision, without harping on your team every 23 minutes. So we see here a direct application of the science of scheduling and managing metrics, paired with the art of invisibility: ninja project warrior!
Vision: Part III - Implementing a vision of ideal communication.
With today's arena of market buzzwords like "synergistic communication paradigm", sometimes it is necessary to cut the fat. Synergy has it's time and place, but visionary communication isn't it. That's not to say don't promote the up-ways/side-ways/diagonal ways communication paradigm you read about in this weeks best-seller on business management, what it means is to establish proper protocol and ensure delegation of authority. So if coder Jane doesn't like the implementation of coder John's function, she's not going to send a message to the PM and open a forum on the topic. She will raise the issue to the code lead, and the code lead is then responsible for communicating the problem to the rest of the code team. When a solution is made, it doesn't take an act of congress to get it to pass. Authority is held by those responsible, and everyone has a stake.
Vision: Part IV - Ensuring a vision of controlled scope.
When it comes to "scope-creep" and "gold-plating", I am exhibit-A. When the terms and conditions of a project are agreed upon, it is the PM's responsibility to ensure everyone involved in the project (the project "stakeholders") has a clear and consistent vision of the project. This may involve depicting certain elements at a very low level at times, depending on the size and complexity of the project team. The art to this is to remind everyone involved, that they had a say in what the final vision was, and it is now up to them to deliver on their promise.
Vision: Part V - Securing management support.
It is imperative to understand that the PM is nothing without the support of upper management and those who pay the proverbial bills. It is the duty of the PM to secure the vision of the project to those who fund it to begin with. This involves things such as persuading higher-ups that John needs that dual-proc Xeon for his development machine or the project is doomed. Now think about it before saying, "He can do just fine with the machine he has!" As a PM, you need to realize that John may be giving you his 'time' every week (which is worth a certain dollar amount), but if you deliver on his request for a beefy machine he thinks, "w00t!", and now not only do you get John's 'time', you also get his 'energy' (which is worth a much greater dollar amount). Again, truly an art.
The project lifecycle
Ok, now that we're all primed up for some project management, I want to introduce the project lifecycle. Placing your project in a position of realistic expectations, and getting everyone to agree on those expectations, along with the implementation of the visionary tasks outlined above, requires the execution of many techniques. From the highest level, these can be broken down into the following lifecycle model.
Project definition
This is where it all starts, and before anything else, this must take place. It consists of formally identifying the project "stakeholders", establishing an organizational structure to the project team, and defining the scope and communication protocol of the project. The execution of this process then yields a "Statement of Work" (SOW) or a "Work Breakdown Structure" (WBS); this is joined by a discrete responsibility matrix, clearly defining who is responsible for what. Basically this defines the rules of the game so to speak. It tells us how to play and what it takes to win.
Project planning
Taking the outputs of the previous phase, the project then enters the planning phase. This is where things like risk analysis, detailed scheduling, and estimation are done. All risks are attempted to be identified here and properly addressed. It is necessary to point out that these are project risks, not implementation risks. Things like: "John needs the wackzit to start implementing the wutzit by 15.June or we'll never meet the schedule!". Not stuff like: "What if the user is running 640x480 and he starts wotnut.net... He won't be able to get to the skagnix control to disable the indexing service!". The results of this process consist of things like risk matrices, schedules, budget projections, and resource plans.
Control
The control phase takes inputs from the previous phase and uses them to perform activities such as progress measurement, communication, correction actions, and finally project closure. All of the phases in this lifecycle model are closed-loop feedback systems. That means, each output is taken as an input to the previous phase in one form or another, corrections and modifications or adjustments are made, and the output is then changed and re-evaluated accordingly until the end of the project.
Conclusion
I will leave the reader at that, for I feel it is enough to take in and digest over a cup of coffee. Each of these lifecycle phases are worthy of an article by themselves, and as such the next article will cover project definition in greater detail. I will also tend to take the series more towards software development projects in particular. I hope you have enjoyed this article and that it has sparked your interest in project management.
