Any framework reflects a balance.

Any framework reflects a balance.


When I asked a sample of my blog readers and podcast listeners whether being on-scope, on-schedule or on-budget defined project success, it was an exercise designed to understand personal biases. Understanding individual and team tendencies are important. However, as we have discussed, the choice of a single attribute without context is just an intellectual exercise. All projects work to find a balance between all three attributes based on their specific business needs and context.

In well-run projects, decisions are not made in a vacuum. The balancing act between the scope, budget and schedule are fraught with difficulties. For example, I recently talked to a friend who as working on a project that included a feature promised to a major customer for their holiday season. The team determined that they were not going to make the delivery date unless some of the project scope is jettisoned (adding more team was not an option at that point). In this case decisions about scope, budget and schedule exceed the product owner’s decision-making authority, even though she was a senior leader. Any solution would affect marketing and sales plans, revenue projections and potentially earning reports. Many voices had to be heard before a path forward was found. All three attributes had to be manipulated to find a solution. In this case scope was deferred, release dates shifted and additional budget provided. It was not a perfect solution, but it was feasible and focusing on a single attribute would have resulted in more problems. The size and importance of any project will affect how large a circle needs to be involved in decisions if the balance of on-scope, on-schedule and on-budget get out of balance.

Some potential combinations of scope, budget and schedule are impossible. As Fred Brooks observed, adding people to a late project will just make it later. When impossible teams are asked to deliver a with impossible constraints they will invariably cut corners, make mistakes, incur technical debt or flat out ignore one of the levers (and then ask for forgiveness).

There is a classic project saying, “on-time, on-budget, or on-scope, pick one.” It has been said that good project managers can deliver two of the three and everyone struggles with delivering all three. Real life projects represent a compromise between all three components. When time is critical, the team might cut the scope or pursue additional resources. On-scope, on-budget and on-schedule can be thought of as three dials with customer and management satisfaction providing feedback. Project teams constantly adjust each dial to elicit positive feedback and to deliver the maximum value possible.




Understanding the project team’s definition of success is important because it helps us understand how the team will behave in crunch time. And yes, crunch time still happens. Recently I asked a selection of podcast listeners and blog readers to weigh in on whether being on-budget, on-scope or on-schedule was the most important attribute of project success. A majority answered that on-schedule was the most important attribute. One of the respondents summed up their rational for choosing on-schedule by saying, “Given the high-paced world we find ourselves in, I think on-schedule is what many now use to judge project “success.”

Dates are projected when a project is conceived. A project will begin on x date and end on y date. These dates create an anchor that will be used to compare performance. Both the business and IT plan based on these dates. A simple example illustrates the cascade effect caused by a project going longer than anticipated. If an e-commerce project has to add two extra, two-week sprints to complete a minimum viable product, the teams working on the project cannot then start the other project they were schedule for when the basic site was completed. That project is now delayed for four weeks, impacting the business and other stakeholders. The rollout of the new site will also have an effect both from an operational and marketing perspective. Plans will need to be adjusted. Because the site is late the anticipated revenues will be delayed and ROI calculation for the project will be impacted. Finally, if the project is large enough, the delay may impact earnings making life uncomfortable for managers and executives. While there are often many reasons for missing the schedule, the schedule miss will be a drag on the perception of success. As another respondent noted, “Oftentimes, I find that the driver of most projects is time…after all, everyone wants things done quickly. These drivers influence successful partnerships or solicitations.”

The news media of all types, popular or technology, continually reminds us that we are living in a very dynamic era. New technologies and businesses rise and fall in a metaphorical blink of an eye. Software and technology are seen as a critical enabler to support the pace of change. Therefore, there is an expectation levied on projects to meet the need for new and changed functionality. Agile methods, which either deliver functionality quickly or continuously, fit well into environments that are dynamic. On respondent suggested that the pace and the focus on being on-schedule was because, “IT projects are no longer simply supporting back office functions.  They are responsible for driving the customer experience.” Customers expect change and systems must evolve to meet that expectation.

The Project Management Institute’s define a project as a temporary endeavor  with a start and end date. Plans are made by the business as well as on a more tactical level within development organizations. When projects don’t happen when they are planned, other projects and events are impacted. Change causes a ripple effect. Methods and techniques like Agile change the playing field by doubling down on the concept of on-schedule. Agile and continuous delivery techniques promise delivery of potentially implementable functionality either as a continuous flow or based on a short known cadence. The customers expectation for when they will get functionality gets set that when we provide a date. Teams tend to pursue the commitments they make, the schedule is often the most obvious of those commitments.

IMG_0696I recently asked  a sample of  the Software Process Measurement blog readers  and listeners of the Software Process and Measurement Cast how they defined project success. I constrained the answers to the classic project management three-legged stool of on-schedule, on-budget and on-scope, to avoid the predominant answer: “it depends.” Even though many of the respondents found the question difficult, everyone had a succinct opinion. The ranked responses were:

  1. On-schedule
  2. On-scope
  3. On-budget

When I asked which of the three “ons” defined project success, the top response hands down was on-schedule with nearly twice as many responses as on-scope. On-budget was a distant third, but interestingly, it was as mentioned as the second most important response on more than a few responses.

I am not surprised by how the responses stacked up. Schedule is the most easily measured and monitored of the success criteria. Everyone knows how to read a calendar, and given that most projects are created with a due date, whether or not a project is on-time is obvious.

On-scope, while representing the voice of the customer, is more difficult for most projects to interpret and measure. Projects (whether Agile or plan-based) generally evolve over the life of the project. That evolution means that the picture any stakeholder, developer or product owner had in their head at the beginning of the project may not represent what has been delivered when the project is completed. Since scope is less tangible, it is perceived to be less important (or at least more easily debated). Being on-scope may be more of a dis-satisfier (if what is delivered not close to what was wanted people will be dissatisfied, however just being on-target or close does not move the needle) than a satisfier.

The final leg on our stool was on-budget. In most cases the true budget of a project is an outcome impacted by schedule and scope, therefore is a metric that all project managers monitor but have few levers to control. Given that budget performance at a project level is deterministic the respondents perceived it as less important. Had I asked a room of IT finance personnel, I suspect that the answer might have been different.

One of the most interesting observations is that even without context everyone had an opinion about the definition of success. While context, if given, may have shifted the respondent’s perspective, their initial response represents the respondent’s natural cognitive bias. When asked to identify whether being on-schedule, on-budget or on-scope was the most important attribute of project success everyone I asked had an opinion. And, that opinion focused on the very tangible and measurable calendar metric: on-schedule. The basic definition of success that a project manager or leader carries with themselves is important because that opinion will guide how they will try to influence project behavior.

Note over the next few days we will explore the rationale behind why each leg of the stool was important to those who responded.

A schedule is not a plan but a plan might have a schedule in it!

A schedule is not a plan but a plan might have a schedule in it!

The first two organizations I worked for called the project schedule the ‘project plan’. A little later when I went to work for an organization that approached project management more formally, I was initially confused when a Gantt chart stopped being a project plan and my trusty plan was replaced by a document indicating how things would be approached rather than what would be done. I still occasionally conflate the concept of a project schedule with a project plan. While the two tools are related, they are different and serve different purposes.

A project plan is a deliverable used to document planning assumptions and as a vehicle to communicate the approved of scope, cost and schedule. Some form of a schedule is typically included in the plan. Inclusion of an early schedule establishes a link between the two deliverables. The Project Management Institute (PMI) indicates that the project plan is a formal, approved document. Formal project plans can include a wide array of sub-plans, including a risk management plan, quality plan or communication plan. Formal, classic project plans can be quite significant documents requiring a lot of effort to prepare. A plan and all of the sub-plans provide a platform for a project manager and stakeholders to develop a common understanding of how a project will be approached and establish roles. Many Agile projects use the Agile Team Charter to set expectations for how the project will be approached at the team level.

A cautionary note: writing and getting a plan signed-off does not ensure that all parties have developed a common understanding. Interaction and conversation are critical steps to developing a common language for the project.

Project schedules come in many forms ranging from simple approaches, such activity lists and time tables, to highly complex forms that include task network-based schedules and Critical Path Methods (CPM). A common thread in most schedules is that features, tasks and activities (or some subset) are documented and connected as a tool to guide the team and communicate progress. Agile teams use prioritized backlogs and release plans as schedules and while other methods use techniques such as milestone charts, task lists, Gantt chats and/or CPM (this only scratches the surface). Schedules act as tools to guide activities in a project, to answer the “when” questions and to help answer the “how much will this cost” questions.

Plans are a mechanism to help teams and project leaders consider how the project will be approached, to define roles and to begin to establish a common understanding between everyone involved. Project schedules reflect how the work will get done and when it will get done. Schedules reflect tactical planning, while plans take a more strategic view. Like planning, all projects use some form of scheduling technique. Team charters, backlogs, release plans, iteration backlogs, task lists or Kanban boards or project plan documents and detailed project schedules, reflect the difference in our approach and philosophy.