Looking at the map to starting an Agile effort?

Looking at the map to starting an Agile effort?

What is needed to start an Agile project?  There are a number of requirements for beginning an Agile effort.  Those requirements typically include a big picture understanding of the business need, a budget, resources, and a team.   Somewhere in that mess, someone needs to understand if there are any unchangeable constraints. A high-level view of the five categories of requirements for starting an Agile effort are:  (more…)

FullSizeRender

The five Agile Portfolio Metrics Categories as whole represent a framework that can be populated with a wide range of specific measures that target specific information needs. The final category in the framework is focused on financial metrics, how we account for the money spent.  (more…)

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.

 

Are budgets always a bit askew?

Are budgets always a bit askew?

I recently asked a selection of the Software Process and Measurement Podcast listeners and blog readers which of the classic three factors; on-time, on-budget or on-scope, define project success. While overall the results are not surprising I expected that being on-budget have had more mentions than the results showed. Of the respondents only one person put on-budget at the top of their list. On the other hand, another respondent took the time to explicitly point out why budget could not be on the top of their list. These are two very different takes on the impact of  being “on-budget” has on determining whether a project is successful.

The first comment was, “From the perspective of the sponsor(s), budget is clearly the thing.  This drives a tremendous amount of organizational behavior.” Budget performance is often tied very closely into managers’ performance objectives, and therefore is tied closely to how they are paid or bonused. In order to maximize their individual pay, the budget is often managed by constraining what is delivered or how work is done (ranging from the processes used to where the work is sourced). I have observed the outcome of budget management in projects over the years, which is why I would have through being on-budget would be higher on the list. Budget management can be a blunt instrument, and improper budget management can cause managers to cut the scope to meet the budget, lower quality due to the constraint of testing as the budget runs out, or even logging time to other projects with available budget. In the Software Process and Measurement Cast 306, Luis Gonçalves suggested that many poor organizational behaviors can be traced back to performance objectives and misuse of goals and objectives.

The second comment was, “No project is ever completely on budget.” This comment reflects a certain fatalism toward budgets (and the budgeting process). As we are all aware, budgets are typically developed and set before the organization truly knows what is being asked for and how it will be delivered. Therefore, unless stated as a range based on probability of budgetary outcomes, cannot be correct. Most budgets are not given or recorded as ranges, but rather as a specific number. The false precision based on imperfect information makes the budget a poor goal with little motivational power on its own.

Being on-budget has impact. Organizations allocate funds for work with the expectation of a return. This simple statement is just as true for software maintenance as it is for new product development. Variance in between what was planned and what was spent will have ramifications. Development personnel for the most part can’t impact the budget directly (with the possible exception of product owners), therefore being teams spend less time thinking about whether they are on-budget than on the attributes they can directly influence.

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.

Do I budget, estimate or plan the number of crawfish I am going to eat?

Do I budget, estimate or plan the number of crawfish I am going to eat?

Software project estimation is a conflation of three related but different concepts. The three concepts are budgeting, estimation and planning.  These are typical in a normal commercial organization, however these concepts might be called different things depending your business model.  For example, organizations that sell software services typically develop sales bids instead of budgets.  The budget to estimate to plan evolution really follows the path a project team takes as they lean about the project.

Budgeting is the first step.  You usually build a budget at the point that you know the least amount about the project. Looking back on my corporate career, I can’t tell how many late nights were spent in November conceptualizing projects with my clients so that we could build a budget for the following year.  The figures we came up with were (at best) based on an analogy to a similar project.  Even more intriguing was that accounting expects you to submit a single number for each project (if you threw in decimal points they were more apt to believe the number).  Budget figures are generated when we know the least, which means we are at the widest point of the cone of uncertainty.  A term that is sometimes used instead of a budget is rough order of magnitude.

The second stop on the estimation journey generally occurs as the project is considered or staged in the overall project portfolio.  An estimate generally provides a more finite approximation of cost, effort and duration based on deeper knowledge. There is a wide range of techniques for generating an estimate, ranging from analogies to parametric estimation (a process based on quantitative inputs, expected behaviors and past performance).  The method you use depends on the organization’s culture and the amount of available information.  Mature estimation organizations almost always express an estimate either as a range or as a probability.  Estimates can be generated iteratively as you gather new information and experience.

The final stop in the decomposition of the from the budget to the estimate is the plan. A plan is the work breakdown structure for the project (generally with task estimates and resources assigned) or a task list. In order to create a plan you must have a fairly precise understanding what you are building and how you are going to build it.  Good planning can only occur when a team is in thinnest part of the cone of uncertainty. Or, in other words, where you have significant knowledge and information about what you are planning.  Immature organizations often build a plan for a project, sum the effort and the cost and then call the total an estimate (this is called bottom-up estimating) which mean they must pretend to know more than the really can. More mature organizations plan iteratively up to a short-term planning horizon (in Agile that would be the duration of a sprint) and then estimate (top-down) for periods outside the short term planning window.

Short Descriptions:

  • Budgeting: Defines how much we have to spend and influences scope.   A budget is generally a single number that ignores the cone of uncertainty.
  • Estimating: Defines an approximation of one or more of the basic attributes that define the size of the project. The attributes include of cost, effort, duration. An estimate is generally given as a range based on where the project is the cone of uncertainty.
  • Planning: Builds the task list or the work breakdown so that resources can be planned and organized. Planning occurs at the narrowest part of the cone of uncertainty.

Estimating means many things to many people.  In order to understand the process and why some form of estimation will always be required in any organization, we need unpack the term and consider each of the component parts.  Each step along the continuum from budgeting to planning provides different information and requires different levels of information ranging from the classic back of the napkin concept (budget) to a task list generated in a sprint planning session (plan).  Having one does not replace the need for the other.