When is a project too small for the formality & structure of project management?

By: Peter LePiane

The struggle is age-old. The project manager is pre-programmed to establish clear goals, scope and deliverables for the project. The client typically just wants the deliverables delivered as soon as possible with minimal overhead and unnecessary formality. Especially if the project is small. After all, why introduce time and effort when it is not required?

Should small projects be exempt from the typical project management rigors of medium and large projects?

For the sake of this article, we will define a small project as less than 10 people (including the Project Sponsor, Project Manager, Subject Matter Experts, Business Analysts and Solution Developers) with a budget less than $1,000,000.

Perhaps there should be a relationship between the total project effort in person-hours and the effort that should be expended for project formality and adherence to methodology. If only it were that simple. Small does not necessarily translate into straightforward. One would assume that if any organization would recommend a prescriptive approach to project management for all projects, it would be the PMI. Surprisingly, the Introduction of the PMBOK states: “Good practice does not mean that the knowledge described should always be applied uniformly on all projects; the project management team is responsible for determining what is appropriate for any given project”.

So what is the project management prescription for a small project sponsored by someone who just wants to see project deliverables? The answer is what I’ll call “right-sized” formality and is really no different than what the Introduction of the PMBOK is alluding to.

Set Your Boundaries

As project managers, we have all developed go-to tools, techniques and templates. For all of us, there is undoubtedly a level of project management formality that we are comfortable with. If our formality line of comfort is crossed, we start to get nervous and feel like the project is loaded with risk. The best way to avoid conflict with a client over the level of formality to be applied to a project is to communicate your minimum level of formality up front as clearly as possible. Know what project rigor you feel comfortable omitting and, more importantly, don’t feel comfortable omitting so that you can set the ground rules for your project early with your client.

Understand Your Client

Once you know where your own boundaries are for project management formality, you must understand what your client’s boundaries are. If the client organization has experience with projects that used project management methodology and templates, you may be able to propose more formality. However, if your client has no experience with project management formality, you will likely have to start at your minimum level of formality and work up from that point.

Sell the Benefits

Armed with an understanding of your client’s exposure to and experience with project management, you can now negotiate and establish the process, templates and techniques of project management methodology to be applied with your client. Because you spent the time to carefully consider what your minimum level of formality is, you also would have conducted a simplified cost-benefit analysis of each piece of formality for yourself. It is this cost-benefit analysis that must be modified (based on the “Understand Your Client” step you would have conducted) and presented to your client so that they can understand the upside to what they may perceive as pure overhead. It is frequently part of our job as project managers to sell the benefits of the methodology, techniques and tools of the profession. This would be one of those times.

Don’t Be Afraid To Walk Away

Based on your experience as a project manager (some of it painful, no doubt) you know what has worked for you and what has not. You have a clear picture of what will yield project success. If after your best efforts to sell them, the client does not see the benefits and only sees costs, you should walk away if you can. There is nothing wrong with professionally stating to your client that you believe that you will not be able to deliver a project that will exceed their expectations. It’s much better to come to that understanding with a client before the project starts rather than once you have reached a point in the project where it might fail.

Small projects often seem like they should be simple projects. We proudly state statistics for our projects in our resumes and LinkedIn profiles like: “managed a team of 40 international developers” or “successfully delivered a $10M project to implement …”. These large numbers seem to carry with them the implication of complexity and challenge. We should be no less proud as project managers of the smaller projects that we successfully deliver. Although their “numbers” may be smaller, their complexities and challenges never are.