Creative thinking can help you combat cognitive biases.

Cognitive biases are shortcuts that people use in decision making.  The shortcuts generated by cognitive biases are typically helpful, which leads to people to internalize the bias. These internalized biases are therefore used unconsciously.  Any behavior that becomes an unconscious response can lead to actions and decisions that are perceived as irrational if the context or the environment has shifted.  For example, a colleague recently related a story about an organization with an emergent product quality problem that occurred after they had disbanded their independent test group. The response was to immediately reconstitute the test group based on the belief that if the independent testing had worked before it would work again. The response was based on a cognitive bias, not a root cause analysis or some form of mindfulness.   (more…)

Mindset Book Cover
Today we review Chapter 6 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  In Chapter 6, we explore the impact of mindsets on relationships.  While this chapter is focused primarily on personal relationships, we can also use the ideas in this chapter to hone relationships within teams and the broader business environment. We can see differences in how in our mindset affects how we deal with the ups and downs of relationships. While the trials and tribulations of more intimate relationships are important, our re-read will ultimately focus on how our knowledge of mindsets can be used in transformations and coaching.

A fixed mindset believes that performance stems from a set of fixed attributes.  Rejection is seen as a reflection of a personal flaw which sets a label (e.g. failure).  When those with a fixed mindset perceive they have a negative label, they will tend to lash out at those around them.  Because they are protecting their ego those with a fixed mindset begin plotting revenge in an attempt to repair their ego. People with a growth mindset will use the ups and downs of relationships as a feedback mechanism. When slights occur they will tend to forgive and move on.

All relationships are a complicated set of interrelated systems.  Making and maintaining relationships takes work. However as we have seen in previous chapters, those with a fixed mindset believe what does not come naturally has little value.  This perception causes those with a fixed mindset to abandon relationships that require work to establish or maintain.  

Another common issue in relationships where one or more partner has a fixed mindset is that assumption that both (or all for different groupings) are of one mind.  This assumption suppresses communication, putting further stress on the relationship and letting individuals ascribe motives to actions and comments that might not be true.

An exercise suggested by Dweck to determine which mindset are being held in relationships is to ask each party the following questions: As a husband, I have the right to ______ and my wife has the duty to _____.  Using a development team as a model – As a developer, I have the right ______ and the tester has the duty to ____.  Switch the role order depending on the primary role being played.  Asking the exercise participants to answer the question will help participants to explain how they anticipate the obligations of a relationship being distributed.  In the process, the words in the stories that are generated will help to expose the mindsets of the particants, which is useful promoting awareness within the relationship.

As we have noted in earlier chapters, problems indicate character flaws to people with a fixed mindset.  At one point in my life, I actually walked away from a friendship when I noticed that someone heavily salted their buttered bread and stopped dating a girl when she put ketchup on a filet.  I believe I have changed, but at the time I saw those problems as insurmountable character flaws.  Rather than discuss the situation (and show a bit more tolerance), I choose to bail out.  These sorts of issues happen in teams everyday reducing team effectiveness.  Remember to confront the situation, not the person.  

In relationships, people with a fixed mindset see others as adversaries to be competed with.  The parties in a relationship that include people with fixed mindsets will often have significantly different power levels (one powerful and the other more submissive).  When those with a fixed mindset see the flaws in their partners they will tend to exploit those flaws to improve their ego and when slighted will seek revenge.  

Organizational Transformation:  Remember that bullying and revenge are influenced by fixed mindsets.  Change can be threatening to people with a fixed mindset. They see change as an attack on their character; threatening their success.  This can be exacerbated if the roll out is done via brute force (bullying) which can generate negative reactions. such as revenge or passive aggressive behavior in the workplace.  As a transformation leader, it is imperative to understand that change can be viewed as a rejection of closely held personal beliefs.  When talking about or leading change separate how you talk about people from how you talk about the roles you are changing.

Team Coaching: Software development has been described as a team sport.  Teams are a reflection of the relationships between team members.  Mindsets can directly affect how team members view each other.  While the chapter focuses on primarily on individual relationships, we can see many of the same patterns in the relationships between team members.  Stress causes individuals with fixed mindsets to focus on the personal faults of others creating distance or even going as far as to ascribe blame to fellow team members.  Coaches have to help teams to separate people from roles and help team members not to blame people, but rather to focus on how to resolve situations and improve outcomes.

Previous Entries of the re-read of Mindset:
Basics and Introduction
Chapter 1: Mindsets
Chapter 2: Inside the Mindsets
Chapter 3: The Truth About Ability and Accomplishment
Chapter 4: Sports: The Mindset of a Champion
Chapter 5: Business: Mindset and Leadership (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.

Trying to read the context...

Trying to read the context…

Many people poke fun at consultants because they invariably use the phrase “it depends,” even when discussing lunch. “It depends” is code for the context of the situation matters to the answer. When I asked a sample of my readers and listeners to weigh in on whether being on-budget, on-scope or on-schedule was the most important attribute of project success, most answered without using the dreaded “it depends”. An excerpt for a recent Twitter conversation in response to the essay about being on-budget, emphasized that in real life the definition of success will be influenced context.

UntitledIn the sample I surveyed, being on-schedule was the most important attribute with on-scope a close second and on-budget a distant third. If I had added constraints to the mix the answer would probably have been different. One respondent, while explaining why they felt that scope was the key attribute of success, made a strong argument for context (without calling it out directly), “Budgets and schedules can be modified when justified, and functionality can be phased in over time.” The statement could easily be interpreted as as a statement that success criteria, at least in the short run, depends on the goals of the business and the context of the project.

We can all conceive of scenarios where a specific context lead one attribute to be viewed as the most important in project success ASSUMING the software does what it is supposed to do and in an adequate manner. As an example of context, one respondent noted that in his environment and for some projects, “regulatory requirements that say it MUST deploy on a specific date.” Failure to meet the date can result in fines or penalties. In a similar vein, another respondent stated, “Projects are often tied to an organization’s business milestones or regulatory requirements so missing the date is not acceptable.” In both cases the context of a project could lead a project team to focus on one attribute over another.

Why did I ask the question without context? As I have noted in earlier essays, we are all subject to cognitive biases. These bias act as filters and shortcuts that help us interpret data. The context of a project will provide information about the goals and constraints of the project. Our cognitive biases are usefully in helping us interpret project context. Which is why project teams with diverse perspectives tend to make better choices when sorting out which attribute is most important. Is one attribute truly more important than another? It depends!




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.

Looking Back

Keep on-scope.

When I recently asked a selection of readers and listeners of the Software Process and Measurement podcast and blog what they perceived as the single most important attribute that determines project success. Everyone that answered had and expressed an opinion on the topic. In order to focus those opinions, I constrained the respondents by asking them to choose from between the classic on-budget, on-scope and on-schedule triangle. In Project Success: An Overview went through the results at a high-level, and on-scope was clear, but strenuously argued second place finisher (far ahead of on-budget). Respondents rationalized the importance of being on on-scope as a connecting/satisfying their customers and as an attribute they had influence over given their span of control.

One respondent stated the augment for on-scope in a very straightforward manner, “I try to remind myself that the business requirements are most important, even if it results in a less-than-technically elegant solution.” The value of any project is tied closely to functionality being delivered. In a similar vein, another respondent suggested that cutting scope hurts the people that need to use the system (paraphrased). If the software or the interface between users of all types does not address the need of the business, it has little value. Scope, whether documented as requirements or user stories, represents a common understanding between customer and developer.

As projects evolve, the scope changes, whether through the adding stories and reprioritization of the project backlog or via change requests in classic project management methods. The processes of accepting change and determining how that change is implemented is usually a negotiation between the team and stakeholders. One of the respondents put it succinctly: “a clear definition of scope and a transparent understanding between our business customers and IT is what makes a project successful.” Involvement in the discussion of what is in scope and how the implicit business discussion is required for transparency and confers importance to the on-scope attribute. If we compare the perceived level of importance of on-scope to on-budget we see the impact of involvement. Budgets are set typically from outside the team’s span of control and act as a constraint for the project team, therefore practitioners see the attribute of on-budget as less important than on-scope.

One response suggested that being on-scope infers meeting functional and performance requirements. While this might not be exactly true, in the hard light of a project the connection between scope and requirements establishes a link between the development team and their customers. The linkage between the team and the customer’s needs makes the relationship between the two groups more intimate and provides the team with motivation therefore the perceived importance of the on-scope attribute.


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.

3-17 2013 bank deposit

When I was working in retail, every day we made a deposit of the day’s receipts.  Once they were safely in the depository, we were done for the day.  While we would all want to bank the gains made through process improvement, our world is not quite as simple. Even though it is difficult to recognize and bank the gains from process improvement, I believe it is always critical. Try to recognize, celebrate and communicate your gains. Not banking your gains will leave you nothing for a rainy day.