Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Project Management

Quote of the Month January 2017

From the Editor of Methods & Tools - Thu, 01/19/2017 - 11:37
Although many organizations are certified at SEI CMM Level 5, when a team hits a production snag, those certificates don‚Äôt carry much weight. People need IT heroes in the team to pull things through. Dependencies on folks who are technically competent, can think on their feet, and can manage time pressures increase that much more. […]

Cone of Uncertainty - Part Trois

Herding Cats - Glen Alleman - Wed, 01/18/2017 - 06:12

The notion¬†of the Cone of Uncertainty has been around for awhile. Barry Boehm's work in ‚ÄúSoftware Engineering Economics‚ÄĚ. Prentice-Hall, 1981. ¬†The poster below is from Steve McConnell's site and makes several things clear.

  • The Cone is a project management framework describing the uncertainty aspects of estimates (cost and schedule) and other project attributes (cost, schedule, and technical performance parameters). Estimates of cost, schedule, technical¬†performance on the left side of the cone have a lower probability of being precise and accurate than estimates on the right side of the cone. This is due to many reasons. One is levels of uncertainty¬†early in the project. Aleatory and Epistemic uncertainties, which create the risk to the success of the project. Other uncertainties that create risk include:
    • Unrealistic performance expectation with missing Measures of Effectiveness and Measures of Performance
    • Inadequate assessment of risks and unmitigated exposure to these risks with proper handling plans.
    • Unanticipated technical issues with alternative plans and solutions to maintain effectiveness
  • Since all project work contains uncertainty, reducing this uncertainty¬†- which reduces risk - is the role of the project team and their management. Either the team itself, the Project or Program Manager, or on larger programs the Risk Management owner.¬†

Here's a simple definition of the Cone of Uncertainty: 

The Cone of Uncertainty describes the evolution of the amount of uncertainty during a project. Uncertainty not only decreases over time passing, but it also diminishes its impact by risk management, specifically by decision-making.At the beginning of a project, comparatively little is known about the product or work results, and so estimates are subject to large uncertainty. As more research and development is done, more information is learned about the project, and the uncertainty then tends to decrease, reaching 0% when all residual risk has been terminated or transferred. This usually happens by the end of the project.

So the question is? - How much variance reduction needs to take place - in any and all the project attributes (risk, effectiveness, performance, cost, schedule - shown below) at what points in time, to increase the probability of project success.

This is the paradigm of the Cone of Uncertainty - it's a planned development compliance engineering tool, not an after the fact data collection tool

The Cone is NOT the result of the project's past performance. The Cone IS the Planned reduction of uncertainty as the project proceeds. When actual measures of cost, schedule, and technical performance are outside the planned cone of uncertainty, corrective actions must be taken to move those uncertanties inside the cone of uncertanty, if the project is going to meet it's cost, schedule, and technical performance goals. 

The Measure that is modeled in the Cone the variable is the Quantitative basis of a control process that establishes the goal for the performance measure. Capturing the actual performance, comparing it to the planned performance, and compliance with the upper and lower control limits provides guidance for making adjustments to maintain that variables performance with acceptable limits.

The Benefits of the Use of the Cone of Uncertainty 

The planned value, the upper and lower control limits, the measures of actual values form a Close Loop Control System - a measurement based feedback process to improve the effectiveness and efficiency of the project management processes by [1]

  • Analyzing trends that help focus on problem areas at the earliest point in time - when the¬†variable under control starts misbehaving, intervention can be taken. No need to wait till the end to find out¬†you're not going to make it
  • Providing early insight into error-prone products that can then be corrected earlier and thereby at lower cost - when the trends are headed to the UCL and LCL, intervention can take place.
  • Avoiding or minimizing cost overruns and schedule slips by detecting them early - by observing trends to breaches of the UCL and LCL.
    enough in the project to implement corrective actions
  • Performing better technical planning, and making adjustments to resources based on discrepancies between planned and actual progress

 

Screen Shot 2017-01-12 at 3.48.34 PM

A critical success factor for all project work is Risk Management. And risk management includes the managements of all kinds of risks. Risks from all kinds of sources of uncertainty, including technical risk, cost risk, schedule, management risk. Each of these uncertainties and the risks they produce can take on a range of values described by probability and statistical distribution functions. Knowing what ranges are possible and knowing what ranges are acceptable is a critical project success factor.

We need to know the Upper Control Limits (UCL) and Lower Control Limit (LCL) of the ranges of all the variables that will impact the success of our project. With this paradigm we have logically connected project management processes with Control System processesIf the variances, created by uncertainty going outside the UCL and LCL. Here's a work in progress paper "Is there an underlying Theory of Project Management," that addresses some of the issues with control of project activities.

Here are some examples of Planned variances and managing of the actual variances to make sure the project stays on plan.

A product weight as a function of the programs increasing maturity. In this case, the projected base weight is planned and the planned weights of each of the major subsystems are laid out as a function of time. Tolerance bands for the project base weight provide management with actionable information about the progression of the program. If the vehicle gets overweight, money and time are needed to correct the undesirable variance. This is a closed loop control system for managing the program with a Technical Performance Measure (TPM). There can be cost and schedule performance measures as well.

Screen Shot 2017-01-13 at 4.23.56 PM

Below is another example of a Weight reduction attribute that has error bands. In this example (an actual vehicle like the example above) the weight must be reduced as the program proceeds left to right. We have a target weight at Test Readiness Review of 23KG. A 25KG vehicle was sold in the proposal, and we need a target weight that has a safety margin, so 23KG is our target.

As the program proceeds, there are UCL and LCL bands that follow the planned weight.  The Orange dots are the actual weights from a variety of sources - a Design Model (3D Catia CAD system), a detailed design model, a bench scale model that can be measured, a non-flying prototype, and then the 1st Flight Article). As the program progresses each of the weight measurements for each of the models through to a final article is compared to the planned weight. We need to keep these values inside the error bands of NEEDED weight reduction if we are to stay on plan.

This is the critical concept in successful project management

We must have a Plan for the critical attributes - Mission Effectiveness, Technical Performance, Key Performance Parameters - for the items. If these are not compliant with the plan will one of the Root Causes of program performance shortfall. We must have a burndown or burnup plan for producing the end item deliverables for the program that match those parameters over the course of the program. Of course, we have a wide range of possible outcomes for each item in the beginning. And as the program proceeds the variances measures on those items move toward compliance of the target number in this case Weight.

Screen Shot 2017-01-13 at 4.21.56 PM

Here's another example of the Cone of Uncertainty, in this case, the uncertainty is the temperature of an oven being designed by an engineering team. The UCL and LCL are defined BEFORE the project starts. These are used to inform the designer of the progress of the project as it proceeds. Staying inside the controls limits is the Planned progress path to the final goal - in this case, temperature.

The Cone of Uncertanty, is the signaling boundaries of the Closed Loop Control system used to manage the project to success

Screen Shot 2017-01-13 at 4.38.04 PM

It turns out the cone can also be a flat range with Upper and Lower Control Limits of the variable that is being developed - a design to variable - in this example a Measure of Performance. In this case, a Measure of Performance that needs to stay within the Upper and Lower limits as the project progress through its gates. If this variable is out of bounds the project will have to pay in some way to get it back to Green

A Measure of Performance characterizes physical or functional attributes relating to the system operation, measured or estimated under specific conditions. Measures of Performance are (1) Attributes that assure the system has the capability and capacity to perform and (2) Assessment of the system to assure it meets design requirements to satisfy the Measures of Effectiveness.

Screen Shot 2017-01-15 at 7.37.49 PM

Another cone style is the cone of confidence in a delivery date. This Actual case it's an Actual Launch date. In this case, as the program moves from left to right, we need to assure that the Launch Date moves from a low confidence Date to a date that has a chance of being correct. The BLUE bars are the probabilistic ranges of the current estimate date. As the program moves forward those ranges must be reduced if we're going to show up as needed. The Planned date and a date with a margin are the build to dates. As the program moves the confidence of the date must increase and move toward the need date.

  • The probabilistic completion times change as the program matures
  • The efforts that produce these improvements must be defined and managed
  • The¬†error bands of the assessment points must include the¬†risk mitigation activities as well
  • The¬†planned activities show how the¬†error band narrows over time
    • This is the basis of a¬†risk tolerant plan
    • The probabilistic interval become more reliable as the risk mitigation and the maturity assessment add confidence to the planned¬†launch date

Just a reminder again - the Cone of Uncertainty is a DESIRED path, NOT the result of an unmanaged project outcome.

Risk Management, as shown below, is how Adults Manage Projects

Screen Shot 2017-01-13 at 7.09.21 AM

Wrap Up On the Misunderstanding of the Purpose and Value of the Cone of Uncertainty

When you hear... 

I have data that shows that uncertainty (or any other needed attribute) doesn't reduce and therefore the COU is a FAKE ... OR ... I see data on my projects where the variance is getting worse as we move forward, instead of narrowing as the Planned COU tells us it should be to meet our goals ...

...then that project is out of control,  starting with a missing steering target that means it's Open Loop Control and will be late, over budget, and likely not perform to the needed effectiveness and performance parameters. And when you see these out of control situations, go find the Root Cause and generate the Corrective Act. 

This data is an observation of a project not being managed as Tim Lister suggests - Risk Management is How Adults Manage Projects. 

And if these observations are taking place without corrective actions of the Root Causes of the performance shortfall, the management is behaving badly. Their just observers of the train wreck that is going to happen real soon.

The Engineering Reason for the Cone of Uncertainty Model and the Value it Provides the Designing Makers

The Cone of Uncertainty is NOT an output from the project's behaviour, by then that's too late.
It's a Steering Target Input to the Management Framework for increasing the probability of the project's success.
This is the Programmatic Management of the project in support of the Technical Management of the project. The processes is an engineering discipline. Systems Engineering, Risk Engineering, Safety and Mission Assurance Engineering, are typical roles where we work.
To suggest otherwise is to invert the paradigm and removes any value from the post-facto observations of the project's performance. At that point it's Too Late, the Horse has left and there's no getting him back.
Defining the planned and needed variance levels at planned points in the project is the basis of the closed loop control system needed increase the probability of success.
When variances outside the planned variance appear, the Root Cause of those must be found and corrective action take.

Resources

[1] Systems Engineering Measurement Primer, INCOSE

[2] System Analysis, Design, and Development Concepts, Principles, and Practices, Charles Wasson, John Wiley & Sons

[3] SMC Systems Engineering Primer & Handbook: Concept, Processes, and Techniques, Space & Missle Systems Center, U.S. Air Force

[4] Defense Acquisition Guide, Chapter 4, Systems Engineering, 15 May 2013.

[5] Program Managers Tool Kit, 16th Edition, Defense Acquisition University.

[6] "Open Loop / Close Loop Project Controls"

[7] "Reducing Estimation Uncertainty with Continuous Assessment: Tracking the 'Cone of Uncertainty',"¬†Pongtip Aroonvatanaporn, Chatchai Sinthop, Barry Boehm.¬†ASE‚Äô10, September 20‚Äď24, 2010, Antwerp, Belgium.¬†

[8]¬†Boehm, B. ‚ÄúSoftware Engineering Economics‚ÄĚ. Prentice-Hall, 1981.

[9] Boehm, B., Abts, C., Brown, A. W., Chulani, S., Clark, B. K., Horowitz, E., Madachy, R., Reifer, D. J., and Steece, B. Software Cost Estimation with COCOMO II, Prentice-Hall,
2000.
[10] Boehm, B., Egyed, A., Port, D., Shah, A., Kwan, J., and Madachy, R. "Using the WinWin Spiral Model: A Case Study," IEEE Computer, Volume 31, Number 7, July 1998, pp.  33-44 

[11] Cohn, M. Agile Estimating and Planning, Prentice-Hall, 2005

[12] DeMarco, T. Controlling Software Projects: Management, Measurement, and Estimation, Yourdon Press, 1982.

[13] Fleming, Q. W. and Koppelman, J. M. Earned Value Project Management, 2nd edition, Project Management Institute, 2000

[14] Galorath, D. and Evans, M. Software Sizing, Estimation, and Risk Management, Auer-bach, 2006

[15]Jorgensen, M. and Boehm, B. ‚ÄúSoftware Development Effort Estimation: Formal Models or Expert Judgment?‚ÄĚ IEEE Software, March-April 2009, pp. 14-19

[16] Jorgensen, M. and Shepperd, M. ‚ÄúA Systematic Review of Software Development Cost Estimation Studies,‚ÄĚ IEEE Trans. Software Eng., vol. 33, no. 1, 2007, pp. 33-53

[17] Krebs, W., Kroll, P., and Richard, E. Un-assessments ‚Äďreflections by the team, for the team. Agile 2008 Conference

[18] McConnell, S. Software Project Survival Guide, Microsoft Press, 1998

[19] Nguyen, V., Deeds-Rubin, S., Tan, T., and Boehm, B. "A SLOC Counting Standard," COCOMO II Forum 2007

[20] Putnam L. and Fitzsimmons, A. ‚ÄúEstimating Software Costs, Parts 1,2 and 3,‚ÄĚ Datamation, September through December 1979

[21] Stutzke, R. D. Estimating Software-Intensive Systems, Pearson Education, Inc, 2005. 

Related articles

Complex, Complexity, Complicated Economics of Software Development Herding Cats: Economics of Software Development Estimating Probabilistic Outcomes? Of Course We Can! I Think You'll Find It's a Bit More Complicated Than That Risk Management is How Adults Manage Projects

 

Categories: Project Management

My Most Popular Posts of 2016

Mike Cohn's Blog - Tue, 01/17/2017 - 16:00

Because I wrote a lot last year--25 blog posts and 50 weekly email tips--I wanted to start something new this year. So here’s a list of the most popular blog posts here during 2016. I hope it helps you catch up on any you missed during the year.

Using our own little algorithm that is a combination of page views, comments and time spent on the pages, here are my top 10 blog posts from 2016, counting down from number 10:

10) Applying Agile Beyond Software Development

Agile can be applied well beyond software development. It’s been used for construction, planning weddings, marketing and more. These are my thoughts on how agile could have saved a hotel chain from an expensive mistake.

9) What Are Story Points?

Story points are perhaps the most misunderstood topic in agile. Story points are not based on just one factor--such as complexity, as is often mistakenly claimed. Instead, story points are based on a combination of factors.

8) Advice on How to Split Reporting User Stories

Splitting stories has long been one of the biggest challenges facing agile teams. Here are some examples of splitting some reporting stories to demonstrate ways of splitting stories.

7) Does a Scrum Team Need a Retrospective Every Sprint?

Conventional wisdom says that a team should do a retrospective every sprint. But if your sprints are one week, can you do them every few sprints? That would still be more often than a team doing four-week sprints.

6) How to Prevent Estimate Inflation

A rose by any other name may smell as sweet, but a five-point story better not go by any other names. Or numbers. Here’s how to maintain consistency across estimates.

5) Summarizing the Results of a Sprint

Although you may wish it weren’t the case, some Scrum Masters need to document how a sprint went. Here’s advice on how to do that in a lightweight, agile manner.

4) The Dangers of a Definition of Ready

After seeing the value of a Definition of Done, some teams introduce a Definition of Ready. For many teams, this is a big mistake and a first step towards a waterfall process.

3) Don’t Estimate the Sprint Backlog Using Task Points

Some teams like story points so much, they invent task points and use those for sprint planning. Bad idea. Here’s why.

2) Sprint Planning for Agile Teams That Have Lots of Interruptions

Most of the Scrum literature describes a situation in which a team is allowed to work without interruption. But that’s not realistic. Here’s how an interrupt-driven team can plan its sprints.

1) A Simple Way to Run a Sprint Retrospective

There are many ways you can run a sprint retrospective. Here’s the simplest way and still my favorite.

What Do You Think?

Please let me know what you think. Is this list missing any of your favorites?

Quote of the Day

Herding Cats - Glen Alleman - Mon, 01/16/2017 - 16:57

MLK

We must learn to live together as brothers or perish together as fools

Categories: Project Management

Available Soon: Co-ownership of Management 3.0

NOOP.NL - Jurgen Appelo - Fri, 01/13/2017 - 14:20

Exactly one year ago, Management 3.0 was named as the front-runner of “The Third Wave of Agile“.

In 2015, the Management 3.0 workshop licensing business grew by 43%.
In 2016, our team was able to grow the annual revenue by another 45%.

What will happen in 2017?

I’m not sure. But whatever it is, you can own and enjoy the results!

Some people have accused me of being a dictator. Indeed, in the last five years, I have always been the single owner of the Management 3.0 business. But I tried to be a benevolent dictator.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Thu, 01/12/2017 - 05:22

Overheard on Twitter

The Start of a Project Is the Worst Time to Estimate Its Duration or Cost

This is only the case if those you've hired know nothing about what capabilities are needed to produce value the project, what Features are needed to produce that Value, when those Value-producing Features are needed to meet the time cost of value payback process, what risks there are for meeting those value producing outcomes, and how the work effort to produce that value are to be measured (physical percent complete) to increase the probability of success for your project. As the project progresses this understanding will, of course, improve with feedback, working product, and learning. 

If those you've hired don't have some sense of these needs, to some level of confidence, you've hired the wrong people.

Screen Shot 2017-01-11 at 8.06.53 PM

From Estimatiing and Reporting Agile Projects with the SRDR

Related articles Managing in Presence of Uncertainty How We Make Decisions is as Important as What We Decide. Planning is the basis of decision making in the presence of uncertainty
Categories: Project Management

Rethinking Component Teams for Flow

A couple of weeks ago, I spoke locally about Manage Your Project Portfolio. Part of the talk is about understanding when you need project portfolio management and flowing work through teams.

One of the (very sharp) fellows in the audience asked this question:

As you grow, don’t you need component teams?

I thought that was a fascinating question. As agile organizations grow, they realize the value of cross-functional teams. They staff for these cross-functional teams. And, then they have a little problem. They can’t find enough UX/UI people. Or, they can’t find enough database people. Or, enough writers. Or some other necessary role for the “next” team. They have a team without necessary expertise.

If managers allow this, they have a problem: They think the team is fully staffed, and it’s not. They think they have a cross-functional team that represents some capacity. Nope.

Some organizations¬†attempt to work around the scarce-expertise problem. They have “visitors” to a team, filling in where the team doesn’t have that capability.

When you do that, you flow work through a not-complete team. You’re still flowing work, but the team itself can’t do the work.

You start that, and sooner or later, the visitor is visiting two, three, four, and more teams. One of my clients has 12 UI people for 200 teams. Yes, they often have iterations where every single team needs a UI person. Every single team. (Everyone is frustrated: the teams, the UI people, and management.)

When you have component teams and visitors, you can’t understand your capacity. You think you have capacity in all those teams, but they’re component teams. They can only go as fast as the entire team, including the person with the scarce expertise, can deliver features. When your team is not first in line for that scarce person, you have a Cost of Delay. You’re either multitasking or waiting for another person. Or, you’re waiting for an expert. (See CoD Due to Multitasking and CoD Due to Other Teams Delay. Also See Diving for Hidden Treasures.)

What can you do?

  1. Flow work through the experts. Instead of flowing work through teams that don’t have all the expertise, ¬†flow work through the experts (not the teams).
  2. Never let experts work alone. With any luck, you have people in the team working with the experts. In Theory of Constraints terms, this is exploiting the constraint. It doesn’t matter what other work you do. If your team requires this expertise, you need to know about it and exploit it (in TOC sense of exploitation).
  3. Visualize the flow of work. Consider a kanban board such as the one below that shows all the work in progress and how you might see what is waiting for whom. I would also measure the Cost of Delay so you can see what the delay due to experts is.
  4. Rearrange backlog ranking, so you have fewer teams waiting for the scarcity.

Here’s the problem. When you allow teams to compete for scarcity (here, it’s a UI person), you don’t get the flow of work through the teams. Everything is slower. You have an increased Cost of Delay on everything.

Visualizing the work helps.

Flowing the work through the constrained people will show you your real capacity.

Needing component teams is a sign someone is still thinking in resource efficiency, not flow efficiency. And, I bet some of you will tell me it’s not possible to hire new people with that skill set locally. I believe you.

If you can’t hire, you have several choices:

  • Have the people with the scarce expertise consciously train others to be ready for them, when those scarce-expertise people become available. Even I can learn some capability in the UI. I will never be a UI expert, but I can learn enough to prepare the code or the tests or the experiments or whatever. (I’m using UI as an example.)
  • Change the backlogs and possibly reorganize as a program. Now, instead of all the teams competing for the scarce expertise, you understand where in the program you want to use that scarce expertise. Program management can help you rationalize the value of the entire backlog for that program.
  • Rethink your capacity and what you want the organization to deliver when. Maybe it’s time for smaller features, more experiments, more MVPs before you invest a ton of time in work you might not need.

I am not a fan of component teams. You could tell, right? Component teams and visitors slow the flow of releasable features. This is an agile management problem, not just a team problem. The teams feel the problem, but management can fix it.

Categories: Project Management

Estimating the Risk

Herding Cats - Glen Alleman - Mon, 01/09/2017 - 19:19

Risk is everywhere on projects. This risk comes from two types of uncertainty. Aleatory uncertainty, which is the naturally occurring yields variances in the underlying processes. This uncertainty is handled with cost, schedule, and technical performance margins. Epistemic uncertainty comes from probabilistic processes that can be addressed with handling responses.

The idea of risk and its management and handling is a critical success factor for all software development.

One of the most rigorous theorems of economics [1] proves that the existing means of production yields greater economic performance only through greater uncertainty that is, through greater risk. While it is futile to try and eliminate risk, and questionable to try and minimize it, it is essential that risk be taken be the right risks...
We must be about to choosing rationally among risk-taking courses of action, rather than plunge into uncertainty on the basis of hunch, hearsay, or incomplete experience, no matter how meticulously quantified.
- Peter Drucker (1975) Management (From The Principles of Software Engineering, Chapter 6, Tom Glib, 1988).

Managing in the presence of risk - and the uncertainty that creates the risk - requires we make risk-informed decisions. These decisions are informed by the probabilistic and statistical outcomes of those decisions in the future. In order to make risk-informed decisions, we must estimate the outcomes and the impacts of those outcomes on future activities (cost, schedule, and technical performance of products and services). Without these estimates, there is no risk management. And as Tim Lister reminds us 

Without these estimates, there can be no risk management. And as Tim Lister reminds us 

Risk Management is how Adults Manage Projects. Be an adult, make estimates of the future outcomes of your risk informed decisions. 

[1] Control or Economic Law Paperback, Eugen von Boehm-Bawerk, 2010.

[2] "How Much Risk is Too Much Risk," Tim Lister, Boston SPIN

[3] "Risk Management is How Adults Manage Projects," Susanne Madsen 

[4] "Risk Management and Agile Software Development," Glen B Alleman

Related articles Essential Reading List for Managing Other People's Money Risk Management is How Adults Manage Projects Herding Cats: Economics of Software Development Herding Cats: Managing Uncertainty, Risk, Threat, and Opportunity What is a Team? Logically Fallacious Friday Herding Cats: Risk Management Capabilities Based Planning Herding Cats: Pictures About Managing in the Presence of Uncertainty Intellectual Honesty of Managing in the Presence of Uncertainty
Categories: Project Management

Scrum & Tests Refactoring in Methods & Tools Winter 2016 issue

From the Editor of Methods & Tools - Mon, 01/09/2017 - 13:36
Methods & Tools ‚Äď the free e-magazine for software developers, testers and project managers ‚Äď has published its Winter 2016 issue that discusses Better Retrospectives, Refactoring Tests, Delivering Scrum Projects and the following free software tools: doctest, MarkupKit. Methods & Tools Winter 2016 issue content: * Making Sprint Retrospectives Work * Embracing the Red Bar: […]

Quote of the Day

Herding Cats - Glen Alleman - Mon, 01/09/2017 - 00:36

It is very tempting to rely on what you are experiencing - Marlene Cimons

Categories: Project Management

Risk Management

Herding Cats - Glen Alleman - Sun, 01/08/2017 - 20:27

Risk Management is How Adults Manage Projects - Tim Lister

Risk ManagementRisk Management requires making estimates of many things. The uncertainties that create the risk - reducible (Epistemic) and irreducible (Aleatory), the impacts from the risks, the efficacy of the corrective actions, the residual reducible uncertainty, and any changes in the irreducible uncertainties.

Just like risk management, estimating is how adults manage projects. No risk management no adult managemnt. No estimates, no adult management. Since as that. 

Categories: Project Management

Economics of Software Development

Herding Cats - Glen Alleman - Sat, 01/07/2017 - 22:15

Making decisions in the presence of uncertainty with limited resources is the domain of Macro and Micro Economics

Making decisions in resource-limited situations at the national or global scale is macroeconomics. Macroeconomics is the study of how people make decisions influenced by tax rates, interest rates foreign policy, and trade policy. Microeconomics is the study of how people make decisions on a personal scale and treats decisions that individual and organizations make. For example, about which software to buy, which Features in the development backlog should be implemented next, what prices to charge for products and services.

Software development is an exercise in microeconomics, since it deals with limited resources - time, cost, and what value is produced in exchange for the time and money.

Because of the limitations of resources, projects need to operate withing a world of limited resources, the uncertainties - both reducible and irreducible - that create risk, and the emerging attributes of all project work. This is the foundation for estimates. Estimates with accuracy and precision values needed to make credible decisions. These estimates are critical to both developers and customers. Underestimating software engineering costs could result in management approving proposed systems that potentially exceed budget allocations, or underdeveloped functions with poor quality, or a failure to complete a project on time. Overestimating costs may result in too many resources committed to a project, or, during contract bidding, result in losing a contract and loss of jobs.

These estimates are used for generating requests for proposals, contract negotiations, scheduling, monitoring, and control.

Managing in the presence of uncertainty requires a Closed Loop Control process. Where targets are set, work is performed, feedback received, corrective actions taken it steer toward the target. Without that target and the error bands on the target and the processes used to steer, Close Loop Control will be ineffective - constantly chasing a moving target, with understanding of what could result, versus what should result. 

Accurate and precise estimates - with predefined values for the accuracy and precision needed to satisfy the attributes of the Closed Loop Control system - are needed because:

  • The work and the outcomes of that work must be classified and prioritized¬†while the project progresses toward the¬†target.
  • Any changes required and assessment of the impact of the change on the cost, schedule, and technical performance of the product or service.
  • To determine¬†what resources¬†to commit to the project and how those resources will be used.
  • Inform those paying for the work, the probability of completing¬†on or before a needed date and¬†at or below needed cost.

Since uncertainty creates risk, managing in the presence of uncertainty is Risk Management. Since risk management is how adults manage projects, † making estimates in the presecnce of uncertanty is adult management.
No Estimates? No Adult Management.

Here are three starting resources for Software Economics:

  1. Software Engineering Economics, Barry Boehm
  2. The Economics of Software Quality, Capers Jone, and Olivier Bonsignou
  3. The Economics of Iterative Software Development": Steering Toward Better Business Results, Walker Royce, Kurt Bittner, Mike Perrow

† Tim Lister, Risk Management is Project Management for Grownups

 

Related articles Pune: Bangalore man arrested in connection with brutal murder of software engineer Economics of Software Development I Think You'll Find It's a Bit More Complicated Than That Logically Fallacious Friday Complex, Complexity, Complicated Herding Cats: Managing Uncertainty, Risk, Threat, and Opportunity Essential Reading List for Managing Other People's Money
Categories: Project Management

Increasing the Probability of Project Success

Herding Cats - Glen Alleman - Thu, 01/05/2017 - 19:35

Increasing the Probability of Project Success
Simple in Theory, Complex in Practice

When we hear any suggestion about improving the probability of success of a project, there are some simple tests to confirm there actually is such a thing. This means having a set of Principles, Process, and Practices to test the suggestion against. Let's start with the Principles

Let's start with the Principles

Screen Shot 2017-01-05 at 9.51.58 AM

These Five Immutable principles are time phased into Processes that provide answers to the Five Principles.

Picture1and the connections between each Process are made to form a Closed Loop control systems needed to manage any project.

Screen Shot 2017-01-05 at 10.02.00 AM

With some details for each process area

Screen Shot 2017-01-05 at 10.03.09 AM

To support these Principles and Processes, a set of Practices are needed

Screen Shot 2017-01-05 at 10.05.43 AM

These charts are an extract from the book Performance-Based Project Management: Increasing the Probability of Project Success and the abstracted training materials Handbook.

Related articles Doing the Math How to Avoid the "Yesterday's Weather" Estimating Problem Hope is not a Strategy Complex, Complexity, Complicated The Use, Misuse, and Abuse of Complexity and Complex Domain is King, No Domain Defined, No Way To Test Your Idea Herding Cats: Quote of the Day
Categories: Project Management

Connecting with Humans

I just read¬†Zappos is struggling with Holacracy because humans aren‚Äôt designed to operate like software. I’m not surprised. That’s because we are humans who work with other human people. I want to talk with people when I want to talk with them, not when some protocol tells me I must.

It’s the same problem when managers talk about “resources” and “FTEs” (full-time equivalents). I don’t know about you. I work with resourceful humans. I work with people, regardless of how much time they work at work.

If the person I need isn’t there, I have some choices:

  • I can cc the “other” person(s) and create a ton of email
  • I can ask multiple¬†people and run the risk of multiple people doing the same work (and adding to waste)
  • I can do it myself—or try to—and not finish other work I have that’s more important.

There are other options, but those are the options I see most often.

We each have unique skills and capabilities. I am not fond of experts working alone. And, I want to know with whom I can build trust, and who will build trust with me.

We build relationships with humans. (Okay, I do yell at my computer, but that’s a one-sided relationship.) We build relationships because we talk with each other:

  • Just before and just after meetings. This is the “how are the kids? how was the wedding? how was the weekend?” kind of conversation.
  • When we work with each other and explain what we mean.
  • When we extend trust and we provide deliverables to build trust.

When we talk with each other, we build relationships. We build trust. (Some of us prefer to talk with one person at a time, and some of us like to speak with more. But we talk together.) That discussion and trust-building allows us to work together.

This relationship-building is one of the problems of geographically distributed teams not feeling like teams. The feelings might be missing in a collocated team, too. Standups work because they are about micro-commitments to each other. (Not to the work, to each other as humans.)

I’m a Spock-kind of person, I admit. I work to build human relationships with colleagues. I work at these relationships because the results are worth it to me. Some of you might start with the people first, and you will build relationships because you like people. I’m okay with that

Categories: Project Management

Managing Uncertainty, Risk, Threat, and Opportunity

Herding Cats - Glen Alleman - Wed, 01/04/2017 - 20:43

I received a book over the Holidays - Managing Project Risk and Uncertainty: A Constructively Simple Approach to Decision Making, Chris Chapman and Stephen Ward. This is a seminal work on risk management in the presence of uncertainty. The introduction has this...

Uncertainty in the plan English sense is lack of certainty has important implication for what can be acheived by organizations. All Management decision should take uncertainty into account. Sometime the implcations of uncertainties are risk in the sense of significant potential unwlecome effects on orgainzation performance. 

Success in the presence of uncertainty requires a process be followed. Here's a recommend one:

  Stage in the Decision Process Uncertainty About Monitor the environment and current operations within the orgainzaiton Completness, veracity, and accuracy of information received, meaning of information, interpretation of implications Recognize the Issue Significance of issue, need for action Scope of decisions Appropriate frame of reference, scope of relevant organization activities who is involved, who should be involved, extent of separation from other decision issues  Determine the performance criteria relevant performance criteria, whose criteria, appropriate metrics, appropriate priorities, and trade-offs between different criteria.  Identify alternative course of action  Nature of alternatives available (scope, timing, and logistics), what is possible, level of detail required, time available to identify alternatives. Predict the outcomes of courses of action Consequence, nature of influencing factors, size of influencing factors, effects and interactions between influencing factors (variability and timing), nature and significance of assumptions made  Chose the course of action How to weight and compare predicted outcomes  Implement the chosen alternatives How alternatives will work in practices Monitor and review performance    What to monitor, how of term to monitor, when to take further actions

In order to make decisions in presence of uncertainty, we need to estimate all the partially elements of the decision process. Withoitn these estimates thetre is no Risk Management. Without Risk Management, there is no SAdult management of the project. 

Risk Management is How Adults Manage Projects - Tim Lister

Categories: Project Management

Self-Healing Systems

From the Editor of Methods & Tools - Wed, 01/04/2017 - 16:33
We can think of the whole computer systems as a human body that consist of cells of various types. They can be hardware or software. When they are software units, the smaller they are, the easier it is for them to self-heal, recuperate from failures, multiply or even get destroyed when that is needed. We […]

Continuous Planning Article Posted

I have a new article up on projectmanagement.com,¬†Continuous Agile Program Planning: Think Big, Plan Small. It’s about how to use rolling wave planning especially for an agile program.

If you are a Product Owner or you are responsible for planning what when, and want to learn how to do this, join my PPO Workshop, starting next week.

Categories: Project Management

Lessons for the New Year

I don’t know if you retrospect on a regular basis. I do. (I know, you are so surprised!)

Andy Kaufman asked me to share my biggest learning for his podcast. Take a listen to¬†The Most Important Lesson You Learned Last Year. I’m pleased and proud to be in such good company. Thanks, Andy!

Categories: Project Management

Accountability on a Agile Software Development in the Presence of Governance

Herding Cats - Glen Alleman - Tue, 01/03/2017 - 02:25

One of the principles of agile development is self-organizing teams.  Self-Organizing is a powerful process. But Self-Directed is not the same as Self-Organizing. On all but de-minimis projects, there is some external organization that is defining what Done looks like at the business capabilities level. In Scrum, this is the Product Owner, who is a member of the team. The PO is defined as:

The keeper of the requirements. The Product Owner provides the ‚Äúsingle source of truth‚ÄĚ for the Team regarding requirements and their planned order of implementation. In practice, the Product Owner is the interface between the business, the customers, and their product related needs on one side, and the Team on the other. The Product Owner buffers the Team from feature requests that come from many sources, and is the single point of contact for all questions about product. The PO maintains the Product Backlog, sets the schedule for releasing completed work to customers, and makes the final call as to whether implementations have the features and quality required for release.¬†

But First a Statement of Principles

Without a set of principles, it's difficult to have a conversation about seeking a shared understanding of the problem and possible solutions for almosty any topic. So for projects that spend other people's money in the presence of uncertainty - Governance is a means to establish those shared principles.

Governance is about Decision Rights. Specifying the decision rights and accoutability framework to encourage desirable behaviours in the developemnt and use of information technology and its supporting services. - IT Governance: How Top Performers Manage IT Decision Risght for Superier Results, Weill and Ross, Harvard Business School Proess.

In this Role (like all members of Agile teams, the PO is a role, not a position) the business value stream is conveyed from the business to the development team through the Product Roadmap and Release Plan. With the Team's full contribution to these artifacts, the Product Owner is Accountable to the business for delivering that value from the Scrum Team's outcomes. This is paradigm is usually found at the Enterprise level of software development. If you're working on a self-contained team, where the customer, PO, development team, and all supporting roles are all sitting at the same table, with a low ceremony around cost, schedule, or deliverable - you can stop reading now. You don't need governance, a Product Roadmap, and Release Plan. Just code and the person paying you will tell you what to do next.

But if you're on a team that gets its funding outside the team, then there is likely a governance process in place for how to spend that money. In this case, there are others who are Accountable for delivery working software. Not designing and developing the software. But those that have a business role for the use of that software to make money or provide a mandated service.This is the Team itself as a collective, but there is a separation of concerns on any non-trivial project as well. The UX/UI designers are Accountable for developing human factors and compliance -

In this governance paradigm, the Team itself is still a collective, but there is a separation of concerns on any non-trivial project as well. The UX/UI designers are Accountable for developing human factors and compliance - 508 Compiance for example - as well as compliance with the current or future UX/UI processes. The Database performance lead on the team is accountable for assuring the code and web service maintain the needed database performance. The Cyber Security lead is Accountable for assure the work of the developers adheres with NIST Cyber Security Framework when the system is public facing with controlled content. The Architect is accountable for assuring the code developed by the Team is compliant with the established Architecture. For example TOGAF or in the DOD, DODAF, or in some other domains industry architectures. IEEE 1553 for real-time embedded system.

In these examples, there is usually some overarching governance process. If yu have no governance process, then none of this accountability discussion is applicable - do what you want not one cares. But if someone does care, usually the customer and those paying, then the notion of Accountability is the basis of project success.

The Responsibility Assignment Matrix

First, there are many alternatives to RACI, so this post is about a Principle and in this case a Practice and Process. On projects where governance is in place, a Responsibility Assignment Matrix (RAM) is a means of defining who is participating in what Role on the project. The RAM defines the single points of accountability for project Leadership Team. These assignments start by identifying who is accountable for which project roles before the project starts. As the project matures, a delegation of these responsibilities down to the project team members using the RACI tool.

In an enterprise project here's an example of the locations for Accountability at the enterprise. 

Screen Shot 2017-01-02 at 9.09.12 AM

 For agile programs, replace the PM with the PO and the diagram above remains the same. From this business governance process, we can build a RAM.

Screen Shot 2017-01-02 at 9.12.35 AM

The RACI paradigm should actually start with Accountability - but ARCI which isn't as snappy. RACI provides the means to flow down responsibility from the Accountability. There cannot be multiple people Accountable, but there can be multiple people Responsible. Without a single point of integrative responsibility, it's not clear who gets to say what about the spending of other people's money. Again if you have no governance process, spend as you wish, do as you wish, no one care. But if there is governance, one place for developers to looks as to WHY governance is needed (rather than saying it's a waste) is Essentials of Managerial Finance, Besley and Brigham. This book explains why and how to manage other people's money when producing products or services in exchange for that money. 

Screen Shot 2017-01-01 at 5.50.50 PM

In The End

If it's your money or maybe your parents money, no one carees how you spend it. But if it's not your money - investors, relatives, the firms money, the stockholders money, the owners money - then some form of governance is likely needed. With this governance paradigm in place, some structure around who gets to decide how to spend that money is likely needed. With that need in place RACI (or its relatives) is a way to have a conversation about who, what, when, and why descioons can be made.

The governance process is based on 3 pillars:

  • Ensure Benefits Realization - this is where the¬†value management comes from
  • Optimize Resources - this is where he¬†cost management comes from
  • Optimize Risks - this is the of removing the impediments of cost, schedule, and technical performance

This is the basis of Governance - It's About Decision Rights. 

No need for decision rights? Spend away

[1] COBIT 5 ISACA's new Framework for IT Governance, Risk, and Security Auditing: An Overview

[2] The Role of ITIL in IT Governance: Leveraging IT Governance around IT Service Management

Related articles Essential Reading List for Managing Other People's Money The Art of Systems Architecting Architecture -Center ERP Systems in the Manufacturing Domain
Categories: Project Management

Pictures About Managing in the Presence of Uncertainty

Herding Cats - Glen Alleman - Sun, 01/01/2017 - 18:13

For projects at scale, meaning the success or failure of the outcome impacts the firm in ways that cannot be corrected if it fails - loss of business, non-recoverable sunk cost, or other unfavorable impacts, there is usually a formal governance process for managing the project, the funding, and the outcomes in a manner that provide visibility to the project progress to plan to the highest levels of the organization.

Many of these Enterprise IT projects apply agile methods. Just as many of the Agile projects in this domain misuse the  Definition of Done. Used as an excuse for not having a plan. Or as an excuse for not defining tangible evidence to needs to be produced in exchange for the investment. Here's a collection of PP&C processes that impact the probability of program success.

Here's the framework for applying Program Planning and Control to Enterprose IT projects as well as the other projects and programs where it is currently used.

Picture1

Let's with a basic idea. All work on projects is uncertain. Reducible uncertainty and irreducible uncertainty. This uncertainty is applicable to all work elements no matter the development method, the system architecture, or any other attributes of the project. Uncertainty is universally applicable to everything we do.

Screen Shot 2016-12-31 at 3.22.57 PM

Some would suggest that haveing no dependencies would remove the impact of uncertainties. But that is no true on any non-trivial project. For example in an enterprise system, like the one below, the needed capabilities to provide value to the business have a logical order. This is a health insurance provider enrollment system. We can have the shared group matrix reports and interfaces until we have a demonstration of the conversion process and member reconciliation. Order, predecessor, and successor relationships are part of all development work. 

Screen Shot 2016-12-31 at 3.26.27 PM

Let's start with some simple statistics. These uncertainties come from the underlying probability and statistics of the work processes. It's important to separate probability from statistics. Both are needed, but they are not the same. And more importantly, they have different impacts on the project. We must learn about the behaviors of both. Reducible uncertainties come from probabilities. Irreducible uncertainties come from statistical processes. One we can do something about and other we must have margin because they are irreducible.

Screen Shot 2016-12-31 at 3.31.19 PM

If you hear about some probabilistic or statistical process, there are some terms that are useful. Here's one - a Probability Distribution Function. This tells us the probability that some value will appear. In this example, those values range from 0.0  to 5.0. As managers, we may only be interested in 80% of the possible value. This 10/90 phrase says that numbers from the 10th percentile to the 90th percentile are the ones we're interested. If there is possibility that a value in the less than 10th percentile or greater than the 90th percent was to appear, we'd need to consider that an outlier or a value that must be prevented from appeared by some means

Screen Shot 2016-12-31 at 3.35.36 PM

As PP&C people we now need to put these concepts to work. The first question to answer is what are the behaviors of the schedule of work. We start with the schedule, rather than cost, because most every non-trivial projects have some deadline to start earning back the invested cost. It's not that we're not interested in cost, but we can usually go beg for more money. We get to beg for more time in any serious project. Why is this true, simple time cost of money. Those investing in the project have a need to start making money from their investment. Or, in many cases, those investing in the project have some external dependency - a launch date for a product. Or a physical launch date - a literal launch date. You can only go to Mars in a small window (weeks) every 3 years. Miss that date, you have to wait - usually at your own cost.

So here's a simple project example. This is from a larger briefing where we use the Wright Brothers contract to deliver a flying machine on a specific date for a specific amount of money. The contract for this machine is 3 pages and calls out dates, cost, measures of effectiveness, measures of performance, and key performance parameters. They had already flown many many times, this was a procurement contract for a production machine. That date was 

Screen Shot 2016-12-31 at 3.48.48 PM

That date was August 14, 1908. Orville and Wilbur were probably not professional Program Planning and Cost analyst, but they knew they to have a credible schedule complete with risk management and risk buy down, margins for that cost and schedule as well as margins for the technical performance of the product. Just like any credible plan for any non-trivial development effort. The Wright Brothers is a good place to learn how it was actually done, and learn that many of things we learning in grade school are not factually correct. The contract Signal Corps Specification No. 486 calls out the details. Wilburn and Orville had he needed margins - developed from reference classes of past flights, experiments, models, prototypes, and intuition. 

In our current domain, the primary tool used to develop the needed margins, assess the impacts of risk reduction activities, find blocking steps and a variety of other reducible and irreducible uncertainties is Monet Carlo Simulation. These simulations are applied to the three core attributes of all project work - time, cost, and technical performance and their interactions.

Here's what that looks like for the planned completion of Work Package #3 on March 12th, 2012. The chart shows there is a 60% probability of completing on or before the need date. If this is acceptable, then fine. If not we need a better plan.

Screen Shot 2016-12-31 at 3.58.31 PM

One of the roles of PP&C is the develop models for the cost and schedule of the project. Then interact with the engineers to assess the plan for increasing the maturity of the deliverables and how hat maturing assessment will impact the cost and schedule when that maturity is not being delivered to plan. This is the basis of a Closed Loop Control system.

Without a plan for delivering the needed capabilities at the needed maturity on the needed date for the needed cost, there is no way to have a control system that will provide actionable information to the decision makers.

 While these charts are notional in nature, here's a real one for dependencies of a large software-intensive system of systems for a flight vehicle. This chart is blurry enough to not be recognizable, but it is real and it represent several billion dollars of work over 5 years

Screen Shot 2016-12-29 at 4.40.53 PM

So In the End

  • Without a plan you don't know what done looks like - don;t believe for a moment the things will emerge and the customer will be happy about what you come up with - unless it's a research project. It's their money and they want to know when they will start earning back that investment
  • Closed Loop Control requires you have units of measure for what done looks like, when that Done will appear, how much it will cost to get to done, what impediments you'll encounter along the way and most importantly what units of measure¬†meaningful to the decision makers will inform the physical percent of the work on the way to done.

This is what Program Planning and Controls does. It does it on large space flight programs. road building, power plant building, and most of all on Agile Software Development projects. Not you're 5 guys at the same table with their customer and an open check book projects. But large software development project (ours are typically $20M or greater up to Billions) with a deadline for working software - all the individual Sprints, Release up to Full Working systems with the needed capabilities to accomplish the mission.

If you have no deadline, no not to exceed budgets, no mandatory capabilities to meet the mission need, no defined benfist from the project, then none of this is useful

Related articles Making Decisions In The Presence of Uncertainty Intellectual Honesty of Managing in the Presence of Uncertainty The Flaw of Empirical Data Used to Make Decisions About the Future Making Decisions in the Presence of Uncertainty Managing in the Presence of Uncertainty
Categories: Project Management