Project Planning and the Art of Management

OK, so I am thinking about how project management workflow seems to executefor a lot of groups and I would like to offer a few thoughts on the topic. I have a bit of education and experience in these areas and I think that I if you don't have a process in place (or at least one that really works), well, you might want to consider the following.

Here are the two items I would like to cover on the topic of Project Management Workflow:

1. Project planning impact (as cost correlates to project activity.)
   


2. Project planning tools and techniques (to improve the situation.)

I think that I am likely preaching to the choir here, but I wanted to put the ideas out there so more folks could keep the discussion going on improving Project Management through improved organization and communication.

Project Planning Impact

In my last ten years (or so) in the field of technology, I have been everything from an analyst, to a project manager (managing multi-million dollar projects) to a designer or developer. While my passion rests with the later, I have something to offer in the first categories. The largest lesson I take home from my experience with project management (and this comes from both the school of hard knocks and traditional Business Administration management university training and the PMBOK from the Project Management Institute) is that the cost on projects increase as the project is being executed, and positive correlation (negative financial impact) between cost increases and project requirement changes as you move down the timeline toward the end of the project. Check out the following diagram:

This happens because requirements are documented (scope is defined) early on and execution of that plan sets a course in the project. When a change to requirements (change to scope) is made later in the project, then efforts made up to that point may be sunk cost and lost benefit and so accomplished work has to be readdressed to accommodate the changes. The more this happens the more we hemorrhage profits from the project. Therefore, a few keys to mitigating this risk would be to do the following:

1. Be as thorough at gathering requirements as is feasible. There are diminishing returns on this and success is determined by how we are able to gather and confirm requirements with the client on a project by project basis.
   


2. Complete requirements (scope) as early as possible. If this is your actual contract for work then the client would need to know that fact.
   


3. Communicate to the client an agreed upon plan for how to manage requirement changes (which are scope changes.) The goal here is to be able to communicate that nothing is ever out of scope so much that money and time cannot fix (assuming we do not alter the quality variable, which I review in a moment.) It is up to us if we want to share the cost of changes with our clients, but there is no reason to not manage that with the understanding of scope.

By having a standard practice in this area we should be able to mitigate risk in the area of timeline as well (not just cost.) If a requirement didn’t get documented then production activities couldn’t have accounted for that and accomplished the task with respect to the timeline. If production activities missed taking care of a documented requirement, then we would know that quite easily as well. If a requirement is added at any point in the timeline we can know two additional time and cost related realities:

1. We can begin to anticipate how the added requirement affects the timeline, the general assumption being, in the minimum, that changes take longer the further down the project timeline you are due to having to readdress accomplished work.
   


2. We can begin to anticipate how the added requirement affects the cost, the general assumption being, in the minimum, that changes cost more the further down the project timeline you are due to having to readdress accomplished work.

The last variable in project management is Quality (the “iron triangle” as it is called is: Quality, Cost and Time) and the rule is that while they all affect each other, you can only consider any two of these three variable fixed at any one time. For example, you can demand a Cost and a Quality as fixed values, but then Time is variably determined by the other two. This means that if the timeline must not change, and we are not going to pass the costs of change down to the client, then one of two realities happens inside the company (you) providing the service:

1. Our "companies" assumes the cost and pays to add resources to get a job done (something my employer recently did on a project to get a large amount of very redudant work completed.)
   


2. Our "companies" adds hours to the timeline in a way that doesn’t affect the client, passing the cost on to employees by adding those hours to their week beyond the typical hours of business operation (if you work alone, this is the equivalent of getting paid less as your pay is now spread across more hours of work.)

No matter the case and outcome our "companies" can manage this reality and the other Iron Triangle (Client, Company and Company Employees/or freelancers personal time) should be aware of how these issues are going to be managed.

Finally, all based on the above, I would like to recommend a technique for documenting requirements that is a lot easier and intuitive to quickly review at a higher level (details still need to be gathered, but this layer pulls everything together.)

Project Planning Tools and Techniques

This section should be quick, as it will require more time to explain / train / learn if you adopt it. There is a ton of information on the internet on how to build traditional Workflow Diagrams.

Check out the following diagram:

Workflow diagrams, like those that one could build in MS Visio, could be drawn up at a high level first. Understanding purpose of each type of box, and each type of workflow, detailed documentation could be textually authored to explain how each box is executed (these details would reflect something closer to what most of us do today.) Basically, the diagrams are a quick way for the client as well as the development team and the project manager/analyst to quickly see how the project will be built. Later when a requirement is added or changed, the PM/A and Designer/Developer can examine the change and more easily estimate the amount of impact on the project. In the above diagram, it might be simple to add the “new activity” (maybe that is Question Randomization in a compliance course) or it may be more difficult, but no matter, we ought to more quickly be able to pinpoint the impact of the change or addition to the rest of the work accomplished as well as secheduled.

So, after that long set of ideas of which, again, I am likely preaching to the choir, please let me know your thoughts about how we might be able to discuss some of this stuff together in a larger forum?

All of this presupposes more open communication with our clients. Often times, we don't want to state the obvious (about billing, change request management, contract details) because it is a touchy subject. But the thing is, I would rather negotiate up-front and not take a job than work on something and not get paid.