IMG_3635The work performed to develop, test and implement any software package is a process flow. Not every team or organization will follow the same flow. Many factors can influence the flow of the work in order to deliver maximum value. Kanban is a popular technique to help a team or organization visualize, control and improve the flow of work so that more value is delivered. Kanban is especially valuable because the visualization exposes bottlenecks and constraints. When applying Kanban, one of the values implicit is adopting wait and see approach to making process changes.  In Kanban, you only make changes when data exposes a constraint or bottleneck. The determination of whether any flow problem is a constraint or bottleneck will affect how they are solved. While similar, bottlenecks and constraints are different and these differences drive how we address them.

A bottleneck is a resource that has a capacity that is less to demand placed on that resource while a constraint is a physical factor that limits performance. Applied to the typical software development or enhancement project, resources typically reflect the amount of effort people can apply. A tester with a backlog of 100 hours of testing to perform would be a bottleneck.  In the same development environment, an example of a constraint would be if the organization had one system testing environment and two teams wanted to use that at the same time and could not due to systemic conflicts. The limitations in the environment would be a constraint. Bottlenecks can be solved by changing or adding resources while constraints require changing the environment as part of changing resources.

Our poor tester is saddled with a backlog of 100 hours of testing.  The backlog reflects a work in progress that is sitting, waiting to be tested to determine whether the code works and meets business requirements. Defects in that code can potentially impact other work that is currently waiting to be tested, currently being coded or work that has previously tested, therefore waiting to test delays feedback.  Two simple changes can be made to improve flow.  The first is slow the amount of work coming to the tester so that work gets to the tester just when it can be tested (reduce the amount of code being written or changed) or increase the number of testers (real or virtual). To remove the bottleneck the organization could reduce the amount of work that needs to be tested or increase the capacity of testing by adding tester. Bottlenecks can be solved by adding, rearranging or reducing resources used in the overall process without changing the environment..

In the article Kanban: Process Improvement and Bottlenecks we used the metaphor of water pouring from a bottle to visualize bottlenecks.  The neck of the bottle is a constraint. If the goal was to improve flow would need limit the amount of water entering the neck of the bottle or remove the constriction.  Adding more neck to the bottle would not affect the flow positively.  In our testing environment example, in order to improve the flow and reduce waiting we would either have to plan project work better so that only one group wanted to use the environment at a time or make a physical change to the test architecture by adding a second (or perhaps more) system test environment.  In order to solve constraints the environment must be changed to solve the flow issue (other resources may also be changed in addition).

Note – Either case requires an overall systems view of the development and enhancement process used by the organization or team. This ensures that removing one constraint or bottleneck just doesn’t create another!

The difference between bottlenecks and constraints may seem to be overly nuanced however understanding that a constraint can be addressed by adjusting resources whereas a bottleneck will require physical changes to the environment is critical to ensuring effective change.

 

Listen to Software Process and Measurement Cast 308 here!

Software Process and Measurement Cast number 308 features our interview with Michael West discussing his book Return on Process.  Process improvement can have a dramatic impact to an organization’s bottom line BUT ONLY with careful thought and planning.  Michael West explains that process improvements with real impact are rarely an accident.

Michael’s bio . . .

Michael West is a life-long practitioner and student of process improvement. He is the co-founder of Natural Systems Process Improvement (Natural SPI), a consultancy specializing in designing, developing, and deploying process systems that enable measurable business performance improvement gains. Mr. West’s process insights and innovations have helped many organizations in various sectors of the economy achieve real process and performance improvement. His process consulting clients include ATK, Autodesk, AVL, BAE, BB&T, Crane Aerospace, DCS, Deloitte, Sandia National Labs, Reliability First, and the US Navy. Mr. West frequently presents and speaks at industry conferences, and is the author of Real Process Improvement Using the CMMI (CRC Press, 2004) and Return On Process (ROP): Getting Real Performance Results from Process Improvement (CRC Press, 2013).

Contact Michael at:
Web: http://www.naturalspi.com/
Email: michael@naturalspi.com
Twitter: @ItsTheProcess

Did you like the interview?  Buy Michael’s books
Return On Process (ROP): Getting Real Performance Results from Process Improvement
Real Process Improvement Using the CMMI

Next

SPaMCAST 309 features our essay on Agile user acceptance testing. Agile user acceptance testing (AUAT) confirms that the output of a project meets the business’ needs and requirements. The concept of acceptance testing early and often is almost inarguable, whether you are using Agile or any other method. AUAT generates early customer feedback, which increases customer satisfaction and reduces the potential for delivering defects. The problem is that implementing an effective and efficient AUAT isn’t always easy.

 

Upcoming Events

DCG Webinars:

Agile Risk Management – It Is Still Important! October 24, 2014 11:230 EDT
Has the adoption of Agile techniques magically erased risk from software projects? Or, have we just changed how we recognize and manage risk?  Or, more frighteningly, by changing the project environment through adopting Agile techniques, have we tricked ourselves into thinking that risk has been abolished?

 

Upcoming Conferences:

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested.

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

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 is 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 is fraught with difficulties. For example, I recently talked to a friend who was 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 scope was 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 based on how they perceive progress. [HUH?] 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!

On-schedule!

On-schedule!

 

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.

Follow

Get every new post delivered to your Inbox.

Join 3,755 other followers