Placing Projects on Hold

In a recent article titled 'Put it in park, then drive' Jack Vinson discusses the potential benefits to project driven organizations of placing certain projects on hold. This seems like a fairly obvious solution but in reality there are potential pitfalls. Primarily, it's likely you've established some sort of deadline with a client, so placing their project on hold may present a problem.

I know that in my world, it would be ideal to be able to work on one project until it was complete. There have been some occasions that we've had the luxury of doing this and the overall product generally ends up being better. Not to mention the resources required to finish the project are usually less than if the project is just one of many.

How could there ever be too many projects in progress? The main problem, which Jack alludes to, is that there always needs to be some 'work in the pipeline' to keep the operation running. If you were to work on one project at a time from start to finish and then start looking for the next project the likelihood is high that you would have gaps in production where people are not doing anything but waiting for the next project.

There is also the issue of having staff that work on different components of a project. If you have a project that requires X, Y, Z from your services it's hard to keep all of the people working on each of those components busy at the same time. The result is that you end up taking a new project on because the 'X' group needs work even though the 'Y' and 'Z' groups are overloaded.

I feel the real solution to being able to keep project oriented staff busy and maintain a decent backlog of work is to be able to accurately schedule resources. If you can do this successfully and communicate the situation up front to your clients you'll allow ample time to give projects the attention they need and hopefully avoid having to park a project once it is started.

Project Communication

It is a common assumption that project managers spend a majority of their time relaying information between project participants (i.e. 'communicating'). In a day and age where communication seems to be non-stop between phone, email, and IM conversations, communication isn't really the problem - the problem is organizing and documenting all of the information that's coming in. You may have a record of all these messages in their native format, but how do you present them for a client review or archive them for future reference?

I know from personal experience that some of the largest chunks of time for a project are taken up sifting through all of the communications, documenting issues and decisions, and reporting this information to the project owner.

KM Executive has a function that helps corral all of this information together into one bucket that makes it much simpler to review when the need arises to perform a review and produce a report. The 'comments' feature allows a task and/or file attachment entry attached to any task that is automatically date stamped. Any phone conversations are documented in this way. Meeting notes are scanned and attached. Critical email conversations are copied and pasted. The end result is a chronological log of all project activities that can be sorted and filtered according to the tags you use for your tasks.