Redefine your project management “solution”

While the promise of project management methodologies is improved efficiency and higher profitability, implementing and sticking to one can be an extremely frustrating endeavour. How often do we observe a “by the book” operation whose participants have completely bought-in to the process and have smiles on their faces?! The issue we’re faced with is twofold. Rigid project management methodologies and their complex software companions are expensive to implement, arduous to maintain, and perhaps are overkill for actual needs. On the other hand, lack of any formal project management can prove to be sloppy, costly, and perhaps worrisome for stakeholders – it’s just not good business. As leaders, what kind of happy medium project management regimen can we implement that works well for our teams, but also gives the impression of legitimacy to our clients and upper management? The answer is not always clear.

As a manager with many hats in a growing professional services company, I’ve had the opportunity to analyze and impact a wide variety of business processes. Streamlining resource scheduling, defining and prioritizing platform developments, automating administrative tasks, and developing HR policies are some of the projects I’ve been involved in of late. I would argue that the type of project management we employ for process and policy improvements and new developments has been a critical factor in our growth.

In this article, I discuss the different types of formal project management methodologies, and provide an overview of the project management regimen that’s been working well at the company I work for, Impetus Digital. Since it’s important to remember where we’ve come from, I’ll start off with a brief retrospect of the discipline.

Project management’s evolution

Although it wasn’t formally studied or considered its own profession until the mid 20th century, project management has been an intrinsic characteristic of civilisation for millennia. Ever since we’ve endeavoured to create products at a large scale – think the Egyptian pyramids and transcontinental railways – we humans have employed thoughtful planning to produce better results, at a cheaper cost, at a faster pace.

At its core, project management is the act of “chunking”: dissecting large, overwhelming bodies of work into smaller, meaningful, more manageable chunks. Additionally, project management incorporates the scheduling of those smaller chunks on a timeline, and assigns groups of people to perform specialized work on specific chunks. With work divided into its component parts, project managers are better able to prioritize and balance the equilibrium of scope, cost, and timeframe of a project – referred to as the “Iron Triangle”. The result is a systematic, efficient approach to creating something, rather than aimlessly throwing in all your resources and hoping for the best.

Project management as a discipline has evolved to become standardized and reflect the differences between industries. Modern PM methodologies can be divided into approximately five types:

  • Sequential (e.g. Waterfall, Critical Path Method)
  • Agile (e.g. Scrum, Kanban)
  • Change management (e.g. Event Chain Methodology, Extreme Project Management)
  • Process-based (e.g. Six Sigma, Lean)
  • Other (e.g. PRINCE2, PRiSM)

Methodology selection is certainly influenced by the operation you’re trying to manage. Some are geared towards manufacturing – think Six Sigma for improving a manufacturing operation, perhaps for ISO 9001 Certification. Others are geared towards product development on a timeline – think Critical Path Method for a product launch, where stakeholders are working against a “drop-dead” date. Regardless of the methodology, the output is a step-by-step process guide for your team to build a successful product.

Below, I’ve summarized the methodologies my company has borrowed from in creating our very own project management regimen. I should note that software development is part of my company’s operation, and some of the methodologies we’ve borrowed from are geared towards that industry – but don’t think that they can’t apply to your operation because you don’t develop software! They’re highly transferrable to projects in any field and business function. I explain why in the next section…

Waterfall. Often referred to as a traditional approach, Waterfall focuses on breaking projects down into a linear sequence of tasks. Tasks are scheduled and the relationships between them, like if the start of one is dependent on the finishing of another, are identified. The output of a Waterfall planning process usually resembles a Gantt chart (or what the PMBoK refers to as a Work Breakdown Structure), whereby tasks are represented by graphical segments on a horizontal timeline. Key concepts of Waterfall include defining clear goals and formulating accurate estimates.

Lean. Although commonly used for comprehensive process improvement in manufacturing, the concepts of Lean project management can be applied to any operation. Lean revolves around delivering more value with less waste by refining and standardizing processes as much as possible. Furthermore, Lean promotes the removal of bottlenecks in production processes to accelerate productivity. For example, removing a “middleman” layer of communication between clients and a production team resembles a Lean improvement.

Agile. The keyword in Agile is “iterative”. Known for its widespread use in the software industry, projects that use the Agile methodology are concerned with delivering value as quickly as possible, and continuously improving by incorporating stakeholder feedback. Planning stages are condensed in this methodology, and feedback is gathered and actioned throughout an entire project – not just near the end. Textbooks often attribute the phrase “minimum viable product” with Agile, and contrast it with the “polished product” result of other methodologies. The main benefits of this approach include a team’s ability to increase transparency, react quickly to evolving stakeholder expectations, and bring something to market as quickly as possible.

Agile: Kanban. The Agile methodology described above consists of multiple frameworks for different types of project teams. Kanban is one of them, and it aims to give operational-type teams a consistent and manageable workload. In other words, it helps teams understand their capacity (i.e. the manageable number of concurrent tasks on their plate), and enables them to quickly switch focus to priority tasks. A distinct Kanban characteristic is its use of a visual task board divided into three columns: To Do, In Progress, and Done. Tasks are represented by cards and placed in the column that represents their status. They’re then moved to different columns as their statuses change.

Agile: Scrum. Another popular framework in Agile is called Scrum. Its differentiators are the strict time intervals it uses called “sprints”. Teams with predefined product development roadmaps often use this method to prioritize work against predefined sprints so they can see progress quickly and continuously deliver. The output goal of a sprint is a “shippable” product. Setting deadlines – often two to four weeks long – pressures teams to focus on a common goal, drop unnecessary components, and, above all, deliver something of value.

Agile: “Scrumban”. As defined by Atlassian in their blog post on selecting an Agile framework (see, “Scrumban” is a happy medium of Scrum and Kanban for teams who need to balance company operations and new product development. Scrumban borrows the sprint concept from Scrum by placing sets of tasks in a timeframe, but leaving enough bandwidth for those “emergency” client requests that will inevitably come up. Of the six methods described here, “Scrumban” has probably been the most influential to me. My team juggles both client-specific needs and new product development for our syndicated cloud platform, so it made a lot of sense to model our development processes on a flexible framework like this.


Building on the popular project management methodologies summarized above, in this section I describe how my company combines bits and pieces of each to form our very own project management regimen. Before I dive in to it, I want to highlight an important consideration we made a while ago at Impetus Digital. Companies rarely seem to follow the predefined methodologies they say they follow. While they might claim they use the Waterfall methodology or the Agile methodology, rarely are things done strictly “by the book”. Generally, it’s not because managers are incompetent or because team members are nonconforming; it’s because process models don’t always fit the mold of a pre-existing team or operation. Knowing that a framework can and should be viewed as a foundation – not a religion – will avoid the inevitable frustration that arises when things just don’t fit. With this mindset, companies can pick and choose the components that work best for them and thereby switch the focus from adhering to process back to creating value, profitably.

As I mentioned in the opener, my company applies a similar project management regimen to all functional areas – from operations and human resources to product development and marketing. Admittedly, we’re a small company, and being small has made it fairly easy to implement change. If you like what you read here, but are at a large company plagued with bureaucracy, I encourage you to at least try to apply some of the concepts on the team level. Perhaps setting an example on a small team will lead to adoption in other parts of the business.

Without further ado, here are the habits we focus on in our project management regimen. I list them in brief first and then elaborate on them below.

  • Work in two-week sprints in all functional areas
  • Set up a full-team meeting rhythm that echoes the sprint schedule, where tasks are prioritized and progress is shared
  • Use the 80/20 rule throughout the sprint (e.g. get something to a “good enough” state and move on to the next task in priority sequence)
  • Keep business objectives and core values close; note how each task planned will help achieve goals or live company values
  • Do as many before-and-after comparisons as possible

Our first habit is adopting sprints in all areas of the business. It’s been super-beneficial for a variety of reasons. Instead of doing massive amounts of planning upfront as in the Waterfall approach, sprint planning is highly condensed since its focus is only a few weeks out. This allows project teams to get to tackling the “actual work” sooner. Another benefit of the sprint is the consistent, but manageable pressure it places on teams. By Parkinson’s law, we humans adjust our work velocity based on the due date. On long projects where due dates might be months apart, productivity is almost certainly lower at the beginning stages. Sprints solve this motivation issue by creating a sense of urgency with each sprint’s commitments. Furthermore, with sprints, the overall quality of work improves because solutions are seen sooner and reviewed more frequently. Defects or problems with the approach can be caught much earlier than in a sequential plan.

Our second habit is aligning full-team meetings with the ends of sprints. Regardless of the project management methodology, meetings play an important role in teambuilding and motivation. While we try to limit meetings as much as possible to keep our workdays productive, we understand we can’t eliminate meetings entirely. As discussed by popular business writer Verne Harnish, in his book, Mastering the Rockefeller Habits, teams need a consistent meeting rhythm to bring focus and alignment, and provide the opportunity to solve problems more quickly. Meeting at the end of every sprint gives us the opportunity to demo our recent achievements, review medium-range priorities, and solidify the task list for the upcoming sprint. Since sprints focus on delivering small, but whole components of a project, it is likely that every team member gets involved in execution in every sprint. In sequential style project management with long planning phases, certain people might not touch a project for weeks or months, depending on when it’s their turn to execute. Full-team meetings that echo sprint cycles will naturally see consistent engagement levels from all team members. This builds commitment and motivation. And, something we’re finding more and more lately is our meeting rhythm is boosting overall empowerment – everyone feels part of the process and there’s less hesitation to take initiative in the sprint model.

Our third habit is instilling the use of the 80/20 rule when working on a new design or development. I’m sure most of you are familiar with the Pareto principle (a.k.a. the law of the vital few), which states that for many situations, roughly 80% of the effects will come from 20% of the causes. We apply this principle to perfectionism by inferring that the last 20% of work on creative tasks takes 80% of the effort. In other words, once you start getting beyond the 80% completion mark of a task, it becomes increasingly difficult and time-sucking to get closer to 100%. Perfection is costly. Using the 80/20 rule can help teams be nimble. By getting something to a “good enough” state, and knowing this is an acceptable approach amongst your peers, you’ll be able to tackle more, and thereby create more value. Using this rule also reduces the frustration, anxiety, anger, and even burnout that go along with always trying to be flawless.

Our fourth habit is focused on keeping close to business objectives and core values when planning for upcoming sprints. Frequently reviewing business objectives is a common practice in any industry, and so I’m sure this habit doesn’t come across as a surprise. I do think the approach we take to applying this habit is unique, though. For example, one of our core values is to “think like a customer”.  On the table we use to list our platform development sprint tasks, we have a column labelled “Client Benefit”. We always need to indicate how will our clients benefit from us completing a given task. We find that going through this step forces us to consider the real outcome of every planned development. Doing so helps us to keep our priorities aligned with our strategic goals. Another part of this habit is the importance we place on tackling the highest impact tasks first. Often what can happen in the execution of a project is the bigger and more ambiguous tasks get left to the end. This is risky business, as delays often occur when dealing with ambiguity, and realized value is lost if the highest impact tasks are saved to the end. By focusing on the “big rocks” first in our sprint planning, we find that we can get more accomplished in the end. (By the way, if you haven’t seen the YouTube video on the rocks and sand analogy for time management by Dr. Stephen Covey, check it out!

Our fifth and final habit often revolves around the act of sharing where we’ve come from and where we’ve arrived. This usually takes the form of metrics and visual comparisons. For an operational project, we regularly estimate the time it used to take to perform a given process, and then calculate the difference after a process improvement. This obviously relates to profitability. On the other hand, for a development project, we regularly compare what a feature used to look like or behave like when we demo an improved version. Doing so helps upper management understand the rationale behind a given task, since they’re not as connected to the minor details of process, and, just as important, it gives us pride in showing improvement. We all know that feeling pride directly translates into job satisfaction – in fact, satisfaction is one of the most coveted things in a job. The more opportunities there are for feeling that sense of pride, the better!

Supplement with technology

Have you noticed that I haven’t mentioned any project management software solution yet in this article? I think it’s important to grasp the underlying processes and habits that go into a project management methodology first before affixing the technology used to facilitate it. Doing so allows you to keep attuned to what the important value supporting aspects are.

As I discussed in the article, it’s very rare that a company will select a project management methodology and stick by it religiously; it’s best when we acknowledge that and adapt to what helps us yield the most value. Once you’ve narrowed in on your process, technology can supplement by automating mundane tasks and improving communication flow.

To wrap things up, two solutions near and dear to my heart are JIRA and Confluence – part of Atlassian’s suite of cloud services. They offer the utmost customization of any project management and team collaboration solution I’ve seen. These tools together can adapt to meet the automation and communication needs of any PM regimen, in all types of industries. I highly recommend trying them out!