Foolish Project Management

fools-hatAs an homage to the fact that it is April Fools Day, a good area to cover would be to examine some of the ‘foolish’ things that can occur in the project management space as well as some of the ‘foolish’ behaviors exhibited by project managers in their day-to-day duties.

Generally speaking, project managers are consummate professionals, leveraging university level scholastic background coupled with years of working experience. Yet as in all things, there exists a fair amount of trial and error when one is acclimating to a new role or is taking on more responsibility as they build their pedigree. We are after-all, human beings and not all our decisions and choices are created equal.

The realm of project management does have variance. Not all project managers will agree on process methodologies, timetable estimation techniques, communication plans, and so forth. Despite that, certain individual behaviors or specific ideas on how to run a project are not always beneficial to the project as a whole. And to be fair, there are also specific choices made by stakeholders or the project sponsor that would also fall into the ‘foolish’ category.

So as a tribute to April 1st, let us examine some of these ‘foolish behaviors’ that may occur in the realm of project management.

‘Foolish’ Scope Definition

As pretty much any project manager worth a salt will tell you, the project scope is one of the most important aspects of the overall project plan. It dictates what key functionality will exist within the deliverable and drives the primary requirements. (For more information on the importance of scope, please view the post: Scope, Time and Cost; Managing the Triple Constraint)

Yet despite the sheer importance of this item, it is striking how many times project managers will overlook or not give enough attention to the scope of their project. What is in scope defines your timetable and modifications to it will change how long it takes to implement. Granted, many times the scope is altered by stakeholders and the project sponsor; but if you as the project manager find you are continuously adjusting the scope because the team did not have a good grasp of what was part of the original scope, you are being ‘foolish’.

‘Foolish’ Project Estimation

The primary project timetable is one of most referenced items by both stakeholders and team members alike. It defines in detail the key milestones, iterations and rollout date of the main project deliverable. Whenever those in the upper echelons of power are viewing status of your project, your timetable and the project progress against that timetable are scrutinized continuously.

So it is fascinating when project managers take a very aloof attitude when it comes to the schedule and the estimates used to derive it. A key fallacy is just taking ‘on faith’ some of the estimates provided by team members as is. In many cases, project managers will discover that members of the team are not great at time management or often times will either be overly optimistic or overly pessimistic when it comes to the schedule. As such, having a mechanism in place such as the Delphi technique, an Agile backlog and so forth will go a long way towards ensuring your schedule and timetable are as accurate as is humanly possible. And if you discover that during the project, you are consistently having to redo timelines and shift the schedule as a whole, you are being ‘foolish’.

‘Foolish’ Resource Management

The majority of projects will have resources associated with them. Depending on the situation, the project manager may have direct control over these resources, but more often than not, it is a dotted line or ‘borrowed resource’ arrangement. Additionally, resources are not always dedicated to a project, but will often have a fractional work load aligned with it. That is when you will hear the use of percentages to denote how much time a resource is allocating to you; i.e. John Smith is spending 20% of his time on your project, or one work day per week.

Understanding how your resources are to be used and how to align requirements and tasks against those resources is extremely important. Yet there are many cases whereby the project manager will either not understand how to align and allocate those resources or simply rely too much on one ‘trusted resource’ while ignoring others. It is a common trap that one can fall into; a team member is responsive and doing their work diligently, so the PM continues to dedicate more tasks to them without factoring in level of effort and how long it will take for that resource to complete all assignments. Also, this leaves many resources somewhat in limbo as they are generally underutilized. This can further complicate matters if a functional manager discovers that one of their resources is not being leveraged on a project and decides to move them out.

A resource allocation matrix is on major benefit here as it will align resources and their requisite skills against the project tasks themselves. Not having this well defined will lead to unbalanced resource assignments, which is another example of being ‘foolish’.

‘Foolish’ Documentation and Process

A project’s process defines how things will get done. It is one of the cornerstone aspects of giving the project team the right information on how they will be doing their work. The process itself is documented into the overall project plan and adjustments can be made as the project progresses. The process can include all aspects of development/construction, quality assurance, integration testing, defect/enhancement handling, and so forth. Understanding the process and ensuring that knowledge is understood by the team members is an important part of ensuring your project functions like a well oiled machine as opposed to a free for all. Yet in many cases, the process is often an afterthought and any documentation outlining the ‘how’ is terse and incomplete.

Without good documentation and process in place, your project is likely to turn into the Wild Wild West. Team members will be tackling their assignments in different ways with no cohesive standard to function against. Different systems and tools will be used, lack of consistency will make duplication of effort rampant and also in the end, torpedo the chance of the project succeeding since collaboration will be all but impossible. Which is why it is imperative to ensure all aspects of the ‘how’ are defined and agreed upon up front. If you are discovering that there is rampant confusion between team members as they attempt to work together and that all your status reports are a collage of different formats, you are being ‘foolish’.

‘Foolish’ Communication

How you disseminate information to the project sponsor, stakeholders and team members is an important aspect of your duties. Keeping people up to date on the project status, timetable, any issues that have arisen, or the task assignments, having a well defined communication plan is important. This can involve explaining to the overall project constituency what mediums will be used and at what frequency things like meetings, email status messages or project ops reviews will occur. Failure to define this well can lead to what some like to call a ‘zombie project’. It has the outward appearance of movement but lacks any effective ways of giving you granular information. The problem in this scenario is that when communication is lacking, a project can eventually start to lose its traction. Additionally, without proper discussions around project issues or tasks, team members will often isolate themselves and produce solutions without properly discussing the outcome to the other team. This can invariably lead to situations whereby one person’s ‘fix’ breaks another person’s current efforts. Keeping the sponsor in the dark or keeping your status messages too rosy (all’s well!) is going to make it more difficult to explain why a problem was allowed to fester for as long as it did before it was addressed.

If you are finding communication lacking in your project, or you discover team members functioning in an environment that is not effectively collaborative, you may be acting ‘foolish’.

‘Foolish’ Procrastination

This one should probably be self explanatory. And you would think it is a non-issue. Yet as stated earlier, project managers are just people and as such, they have all the flaws that come with that. Being a procrastinator does not necessarily mean you are lazy; but what it can be is a symptom of an individual who dodges the more difficult aspects of their job in favor of some of the simpler items thereby creating a higher likelihood of being under the gun. It is inherently human nature that we generally don’t want to do tasks that are either difficult of mundane. But leaving all those types of tasks to the last minute can lead to a scenario where you will end up not doing an effective job on those tasks because you are rushed. Also, more difficult tasks generally have a certain level of unpredicability; i.e. you don’t necessarily realize how difficult until you start. So issues may arise that even you did not anticipate and consequently, you are even worse off.

This problem goes for project team members as well. Which is why it is often important to ensure that when possible, more complex tasks are tackled up front. Invariably, this will give the project more breathing room and allow for any issues that may have arisen with the more difficult tasks to be addressed earlier in the project cycle. And in certain cases, you may be able to justify extra help or resources as needed, which would be more difficult towards the end of a project cycle.

If you are discovering that the project is always feeling ‘rushed’ or riding on the razors edge when it comes to task completion, for both yourself and the project team, you may be acting ‘foolish’.

Conclusion: Don’t be a fool!

In closing, to put it simply: try not to act too ‘foolishly’. Being diligent about some of the aforementioned trouble items will go a long way to giving you breathing room during the project’s life cycle as well as keep you on your toes when it comes to project problems. Dilbert may have hit this one in the bud: