By Craig Covello, PMP:

As I write, there is a beautiful view reserved for travelers 30,000 feet above California, en route to Dallas. It’s a frequent trip these days that gives me pause to consider the perpetual to-do list on my Android. One of those items, it seems, was a promise to write a project management article regarding the difference between small and large IT projects. Admittedly, I have been procrastinating for the last couple of weeks – possibly because this topic can be somewhat subjective, depending upon where you sit and what responsibilities you may have. Since I prefer to deal with specifics, perhaps some alignment of perspectives and definitions is in order.

Large projects, if we choose to accept that label, can be defined many different ways, including the size of budgets, the number of stakeholders, the project duration or even the complexity and/or levels of detail in defining project tasks. Then again, perhaps from the project sponsor’s viewpoint, a large project might be better defined in terms of potential revenue, associated risk or political visibility within the organization. Some of these attributes could be sized using an associated metric, while others are based solely upon perception and politics. For the sake of discussion, perhaps we can simply agree with the assumption that “large projects” all have some significant level of effort that hopefully will benefit the organization at an enterprise level.

In contrast, “small projects” might be described as endeavors that benefit the organization on a more modest scale, perhaps within scope defined by facility or department boundaries. It might also be fair to assume that the project duration, complexity, risk and stakeholder roster is modest as well.

So both ends of this spectrum beg the question: Should small projects be managed differently than large projects? In my opinion, the answer is no. A spectrum is just as the word implies: It is a continuum with no lines or boundaries, only levels of degree based upon perception and political influence. This subjective mindset might leave us without a strategic vision when defining a project charter and an associated project plan of attack. The fog may clear, however, if we fall back to a core frame of reference defined by some best practices and principles common to all projects, including:

  • Sponsorship
  • Funding
  • Objectives
  • Stakeholder Identification
  • Progress Tracking Strategies and Triggers
  • Communication Plans
  • Team Formation
  • Roles and Responsibilities
  • Task Schedules
  • Major Milestones
  • Risk Assessment
  • Quality Assurance
  • Deployment Plans
  • Contingency Plans
  • Success Measurement Metrics
  • Termination Plans

If the list seems unreasonably long, particularly in the context of smaller efforts, then you might take some solace in knowing that each of these aspects should be tailored to meet the unique and specific needs of each project. After all, the word “project” implies something new and special, requiring a creative management style and flexibility of execution typically not found in the day-to-day operations of the enterprise. PMI describes a project as:

“… a temporary group activity designed to produce a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.”1

Unfortunately, the descriptor “project” is too often associated with operational activity, such as printer deployments and work station imaging, which belies the true meaning of the term. Projects do not follow a routine or a repetitive sequence of tasks.

No, I don’t believe there is a difference between large and small projects. But there are differences among all projects. And unlike the emergency lift vest under my seat (remember, I am writing this at 30,000 feet), one size does not fit all when it comes to project execution and tracking. It is just as inappropriate to burden limited-scope projects with excessive communication plans, status meetings and procedures as it is to implement an enterprise-level effort casually, without due diligence. The mix and balance of best practices is ultimately decided by project managers (PMs). That may be difficult since managing projects effectively is sometimes more art than science. It’s fair to say that good PMs do not check off template boxes. They create an efficient environment that enables participants to contribute their diverse talents with limited conflict or confusion.

I once knew a senior executive who held the firm belief that projects requiring $200M in funding should be managed entirely differently than projects below $5M, simply because of size and scope. He maintained that belief right up until his departure, but not before burning through $150M of project funding. Are large and small projects different? You decide, but remember that money is all green, regardless of the size of the stack.

Reference:
1. http://www.pmi.org/About-Us/About-Us-What-is-Project-Management.aspx

2 replies
  1. Dennis Vlasich
    Dennis Vlasich says:

    In my experience, the only difference between a large project and a small project is the number of meetings required.

  2. Bill Flury
    Bill Flury says:

    Managing a large project is not just a case of scaling up what you have been doing on small ones. On a large project you have many sub projects or tasks, each one with a leader and you have to manage through them. You have to make sure that they do all the great things you would do if you were managing the tasks you have assigned them. And, to add to the complexity, you have to make sure that they all communicate among each other and play well together. Not as simple as it may appear.

Comments are closed.