How to Prevent “Small” Department Projects from Creating Enterprise Risks

Have you ever thought something was going to be a minor commitment of time and effort just to find out the opposite later on? Like the email you think will take 5 minutes to write but ends up taking an hour?

Happens rather frequently, to be honest, especially in companies.

What initially may seem like a small initiative or goal within a department may actually be a project that could potentially and inadvertently create new risks to both the department and the broader enterprise.

At best, the “non-project project” ends up failing and wasting money and the time of both the department’s personnel and others across the company. At worst, the impacts cascade into full blown enterprise risk(s) that can put entire strategic goals in jeopardy.

According to the Project Management Institute (PMI), for every $100 invested in projects worldwide, $13.50 is lost right off the top. But monetary loss is just one potential consequence, as enterprise risks borne out of departmental activities can lead to lost opportunities, a damaged reputation, reduced employee morale, and more.

Project failure or success is not determined by size – even organizations with mature project management processes have project failures. Common reasons can range from lack of commitment and unrealistic timelines to competing priorities, insufficient resources, or unclear expectations.

To be clear, we are not talking about larger-scale enterprise-wide strategic projects like in this article, but rather smaller departmental-level ones. While these efforts go unnoticed one-on-one, they can be costly to the company as a whole, or as explained in the book Project Management for the Unofficial Project Manager:

Big projects have plenty of oversight and corrective action when needed. The greater challenge is the everyday “small P” projects. While these projects are small in scope, there are hundreds of them and no one is paying attention.

Allow me to share a story from a consultant on my team to illustrate this point.

A department of one of our clients wanted to bring on a new software system. Simple enough, right?

That’s what the client initially thought…

When it comes to technology, though, even the simplest of tasks can have an impact on other people, processes, and procedures and ultimately introduce new risks.

In the case of this new software, the department eventually realized it needed to coordinate with other areas of the company, which led to questions they were unprepared to answer, like:

  • Is the software going to meet the needs of other departments?
  • Who will manage users or otherwise administer the software?
  • What kind of info with the system contain?
  • Will info create any data privacy issues?

Now it’s completely appropriate for this to happen in the beginning stages of the effort, but in the case of our client, they were (against our advice) at the point of purchase before even engaging with other departments. It was only by accident the risks and potential issues were uncovered. For example, they found out another department would need the software to have a certain functionality for the tool to work for the whole organization.

By not taking the time to think through the project during the infancy stages of this endeavor, situations like this and others lead to resources being pulled away from other departments (and other projects) and disruptions to their whole routine and other work obligations. Even worse, the original “project” ends up being shelved as it’s determined the resources from other departments will not be available.

Simply going forth without any consideration of other areas that could be impacted is an example of silo thinking at its finest.

To avoid this outcome, departments need to recognize when a project (task or department initiative) is really a Project (project spanning multiple departments).

Recognizing something is a Project helps reduce or eliminate chances of failure because you’re identifying action steps and managing them to get to your desired end point.

In terms of PMI standards, this means initiating a process from the beginning to do the following:

  1. Define a scope and schedule
  2. Map out everyone’s vision for the project.
  3. Understand any risks so they can be integrated into the project management process from the onset.

Like strategic goals, involving implementers and key stakeholders from the outset ensure any risks that can cause the effort to fail are adequately addressed and the needed resources to complete the effort will be there.

To determine if an initiative or effort is indeed for a project, departments must ask whether it impacts or will require involvement from other departments and if it comes at a significant cost. If the effort is going to take more than X hours over X days, then it should be considered a Project. Stakeholder expectations also play a huge role in whether something should be defined as a project or not.

Whether classified as such or not, working on “projects” consumes anywhere from 60-80% of the employees time on average according to the authors of the book Project Management for the Unofficial Project Manager. In spite of this fact, almost none of these employees have any formal project management training.

This represents a huge and growing source of risks for companies across-the-board.

In their zeal, managers (like executives) tend to neglect these steps and unintentionally waste vast amounts of resources and open the organization up to risks it would not otherwise have. Avoiding this outcome is why it’s important for department managers and personnel to take a step back and make sure their initiatives are not Projects that require a heightened level of examination.

Has your company been negatively impacted by departmental activities that should have been considered Projects?

I invite you to share your thoughts and experiences on this important, yet underappreciated, topic. Please don’t hesitate to leave a comment below or join the conversation on LinkedIn.

While project management is a well-established best practice for larger initiatives, there is much room for improvement when a company drills down to the departmental level. If your company is looking for how it can improve its management of these “small p” projects and is struggling to know where to start, feel free to reach out directly to schedule a one-on-one consultation to discuss your challenge and potential solutions.

Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

Receive Our Weekly Blog Updates

Meet Carol Williams, SDS Founder & Lead Strategist

To our readers:

This blog was launched to provide strategy and risk practitioners with a go-to resource to better guide their efforts within their companies. Thank you for bringing me and my team along to be part of your journey towards better risk management, strategic planning and execution, and overall decision-making. Happy reading!

Find more SDS Insights