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!

Herding Cats - Glen Alleman
Syndicate content
Performance-Based Project Management¬ģ The Principles, Practices, and Processes to Increase Probability of Delivering Large Scale Projects On Time, On Budget, On Value.
Updated: 1 hour 6 min ago

Quote of the Day ‚ÄĒ Just a Little Process Check

Fri, 08/29/2014 - 15:12

Everyone is entitled to his own opinion, but not his own facts.‚ÄĒ Daniel Patrick Moynihan

When engaging in exchanges about complex topics like cost, schedule, and technical performance management, I always get a smile when someone says oh that problem can be solved with this simple approach. Or I bet that organization has no motivation what so every to solve the problem. 

Then the next quote is applicable...

For every complex problem there is an answer that is clear, simple, and wrong. ‚ÄĒ H. L. Mencken

Solving complex problems is hard, stating there are simple solutions without having worked on complex problems is easy.

Related articles Complex Problems Require Better Solutions The Three Elements of Project Work and Their Estimates The Power of Misattributed and Misquoted Quotes Is There Such a Thing As Making Decisions Without Knowing the Cost?
Categories: Project Management

Quote of the Day - All Things Project Are Probabilistic

Wed, 08/27/2014 - 16:28

As far as the laws of mathematics refer to reality, they are not certain, as far as they are certain, they do not refer to reality.

‚ÄĒ Albert Einstein Sherwin, Ronald Paul (2014-08-17). In The Tao of Systems Engineering: An Engineer's Survival Guide (pp. 195-197). Ronald Paul Sherwin. Kindle Edition.

When ever you hear that we can't predict the future. Think again. We can always predict the future. The level of confidence of that future is what is in question.

When you hear estimating is guessing. Think again. That person doesn't understand probability and statistics. When you hear we don't need to predict to make decisions, that person has very little at risk from that decision, since making decisions in the absence of knowing the possible loss ignores the principles of microeconomics of everyday life.

When ever you hear we don't need to estimate the outcomes of our decisions. Think again. We don't need to estimate those outcomes only if they are of low enough value that we don't care about the consequences of not knowing to some level of confidence what happens as a result of our decision. We're willing to wright off our loss if we're wrong.

When we hear any conjecture that involves mathematics that does not address the foundation of the mathematical principles of that discussion, remember Einstein, and also remember how to apply that advice in the specific domain and context of the question guided by Deming.

Management is Prediction 

Deming 2

Since management is prediction, knowing how to make predictions using statistical methods to produce a confidence interval about the probabilistic outcomes of those business decisions is part of management. When we want a sit at the table where management decisions are being made, knowing this and being able to add value to the decision process is the price of entry to that room. Otherwise we're labor sitting outside the room waiting for the decisions to be made. 
 

Categories: Project Management

Navigating the Way Home

Wed, 08/27/2014 - 03:10

Manx shearwaterI came across a nice blog post from DelancyPlace about the navigation powers of birds. 

This bird was taken from Wale's to Venice Italy and released and found it's way home in 14 days. 930 miles, over mountains .

To be able to find their way home from an unfamiliar place, birds must carry a figurative map and compass in their brains.

The map tells them where they are, and the compass tells them which direction to fly, even when they are released with no frame of reference to their home loft.

Projects Are Not Birds

As project managers, what's our map and compass? How can we navigate from the start of the project to the end, even though we haven't been on this path before. 

How can we find our way Home?

We have a map. It starts with a Capabilities Based Plan. The CBP states what Done looks like in units of measure meaningful to the decision makers. These units of measure are Measures of Effectiveness and Measures of Performance.

  • Measures of Effectiveness - are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions.

  • Measures of Performance -¬†characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions.

These measures speak to our home and the attributes of the home. The map that gets us ti home is the Integrated Master Plan. This shows the increasing maturity of the deliverables that implement the Measures of Performance and those Performance items that enable the project to produce the needed capabilities that are effectively accomplish the mission or fulfill the business need. 

This looks like a map for the increasing value delivery for an insurance company. The map shows the path or actually paths to home. Home is the ability to generate value from the exchange of money to develop the software.

Project Maturity Flow is the Incremental Delivery of Business Value

Related articles Golden Ratio Managing In The Presence Uncertainty Impact Mapping and Integrated Master Planning We Can Know the Business Value of What We Build All Project Work is Probabilistic Work 5 Questions That Need Answers for Project Success
Categories: Project Management

Quote of the Day

Tue, 08/26/2014 - 13:16

"All the mathematical sciences are founded on relations between physical laws and laws of numbers, so that the aim of exact science is to reduce the problems of nature to the determination of quantities by operations with numbers."
‚ÄĒ James Clerk Maxwell, On Faraday's Lines of Force, 1856

Categories: Project Management

Management is Prediction - W. Edwards Deming

Tue, 08/26/2014 - 01:44

DemingThis statement Management is Prediction is the basis of the microeconomics of writing software for money, someone else's money. 

Along with the quote of Daniel Boorstin's,¬†The greatest¬†obstacle to discovery is not ignorance ‚Äď it is the illusion of knowledge. Boorstin was the Librarian of Congress. One of his other quotes was once the subtitle of this blog¬†I Write to Discover What I Think.

And here's what I think about the predictive nature of managing projects. If we don't know how to estimate the impacts of our decisions on the future outcomes of those decisions, we have the illusion of knowledge, when in fact we have no knowledge.

There is a popular myth, that estimating the future outcomes of our present day decisions is somehow voodoo, guessing, making things up, and having our management treat them as commitments. It's clear we didn't pay attention in the probability and statistics class. Or worse yet, we have intentionally ignored what we did learn in that probability and statistics class. Thinking naively or with intent ignoring the probabilistic nature of all project work.

All variables in project work are random variables. These variables are almost always coupled to each other in some way, usually a non-linear way. Fix one variable, the other two are free to be variable. Fix two variables, the third variable is free. Fix all three, they still vary. This is the primary reason margin is needed for project to have a credible chance of showing up on time, on budget, and on value. These variances are Irreducible, meaning they will vary no matter what you do. Fixing Budget, only fixes the amount of money you've allocated to the project. It doesn't fix the cost to produce the value from the project, nor the time to produce that value.

Slide1

So Why Do We Estimate?

When ever possible we should use evidence in making decisions about project variables. Observing the behaviour of the variables in an attempt to see what they are doing, where they are going, what the next outcome might be. 

This is the basis of the OODA Loop. Boyd was an Air Force fighter pilot, and like Jeff Sutherland of agile fame, understood that emerging situations are the norm in the skies of Vietnam, just like they are on projects.

OODA ClipThe OODA loop is often popularized as four elements going around in a circle. The picture is the only diagram Boyd ever drew. Boyd's OODA Loop describes the details. The title of the chart above comes from one of our briefings for Managing in the Presence of Uncertainty. But the domain OODA is applicable is not restricted to DOD acquisition, but is applicable in any domain where money, time, and performance are at risk.

Just to push a little harder, when you hear about Clausewitz and Tzu from agile coders, remember Boyd's comments when he spoke in public

‚ÄúDon‚Äôt be a member of Clausewitz‚Äôs school because a lot has happened since 1832,‚ÄĚ he would warn his audiences, ‚Äúand don‚Äôt be a member of Sun Tzu‚Äôs school because an awful lot has happened since 400 BC.‚ÄĚ

So just like those reference to 1968 reference to the Software Crisis - a lot has happened since then.

So Here's a Simple Fact

Also often ignored by some wanting us to learn to decide without knowing the impacts of those decisions.

People learn better when they predict

Making an estimate about the future ‚ÄĒ predicting¬†on outcome or impact ‚ÄĒ forces us to think ahead about those very outcomes. Making an estimate causes us to examine more deeply the system we are observing and our engagement with that system and our reactions to the system. It causes us to question our understanding of the system as it is now ‚ÄĒ in ¬†its current state ‚ÄĒ and what we would like it to be in its future state. As well, by making estimating about future outcomes, we can learn more about our understanding of the management beliefs we hold as we examine the results of our predictions.

So like Deming tells us ...

Management is Prediction

Not making prediction's about the impact of our decisions, the processes affected by those decisions, like - cost, schedule, and technical performance - shown in the three legged picture above, ignores the principles of Deming. And when we do that, ...

... we're not managing how we spend other peoples money.

The only way this notion can't be called bad management is if the amount of money at risk is low enough that those providing the money don't care if we waste it or not.

Related articles Making Estimates For Your Project Require Discipline, Skill, and Experience Why We Must Learn to Estimate The OODA Loop - Insight into Strategic Thinking An Agile Estimating Story Averages Without Variances are Meaningless - Or Worse Misleading Four Critical Elements of Project Success The Value of Information What does a "broken OODA loop" look like? How To Create Confusion About Root Causes
Categories: Project Management

What I Don't Know Can Actually Hurt Me

Fri, 08/22/2014 - 19:23

Ostrich Head in SandThe notion of not knowing the impact of decisions, choices, approaches is like putting your head in the sand because you don't like the answer or don't what to know the answer.

In our domain there are three common root causes for program difficulties when the program overruns it's budget, shows up late, or the delivered product doesn't work as required

  1. They couldn't know - the source the problem was in fact unknowable.
  2. They didn't know - the source of the problem was knowable, but the effort to discover it was done.
  3. They dodn't want to know - the source of the problem was there, but if it was made visible the project would be canceled or not started

When I read about decision making processes like ...

Screen Shot 2014-08-22 at 12.07.24 PM

I'm struck by the 3rd statement. Knowing something about the cost of a decision, the outcome of an investment, the risks, scope impact, progress reporting of future values requires you make estimates. Since all project variables are random variables that interact in random ways - technically non-stationary stochastic processes - knowing about the impacts from deciding anything using these variables means estimating the three core variables of all projects, shown below.

When I hear the suggestion that decisions can be made in the absence of those estimates, think of the Ostrich, ask the following:

  • Can I decide about some future outcome without estimating the impact of that outcome?
  • If I'm going to invest - spend money - can I do the ROI calculation in the absence of the estimate of the cost or the value - since neither of those are known on day one?
  • Risk - by it's very definition - is an uncertainty. These uncertainty are probabilistic outcomes of future events. Estimates are needed.

If there ways to decide these things without estimates, let's hear them. Each of the three variables and each of their drivers is a random variable whose value is not know in the present, but can only be knowing with an estimate of it's future possible values.

Screen Shot 2014-08-22 at 12.11.42 PM

Related articles Resources for Moving Beyond the "Estimating Fallacy" Making Estimates For Your Project Require Discipline, Skill, and Experience Four Critical Elements of Project Success First Comes Theory, Then Comes Practice How to Deal With Complexity In Software Projects? Statistical Process Control The Basis of All Modern Control Systems Let's Stop Guessing and Learn How to Estimate The Value of Information Why is Statistical Thinking Hard?
Categories: Project Management

No News is Bad News - Feedback Must Create Steering Signal from Plan †

Wed, 08/20/2014 - 22:41

Screen Shot 2014-08-20 at 12.39.03 PMProject Manager: How's the project progressing to plan? 

Developers: We're spending money, consuming resources, producing outputs that the customer likes. 

Project Manager: I was more interested in what's our performance against our planned spend, planned resource consumption, and planned outputs of value to the customer? 

Developers: What do you mean, we didn't estimate any of that, we're managing this project with #NoEstimates. You know that new alternative to estimates for making decisions in software development. That is ways to make decisions with "No Estimates." of the impacts on the future of those estimates or of our work on the future cost, schedule, or technical performance. You know where we can use Decision making frameworks for projects that do not require estimates, or apply Investment models for software projects that do not require estimates, and have our project management methods for risk management, scope management, progress reporting, not require any of those annoying estimates. 'Cause we kinda suck at them anyway, so we just decided instead of learning how to estimate, we'll just not estimate and get back to coding.

Project Manager: Oh, you mean that approach of managing other peoples money that violates the principles of software microeconomics with Open Loop Control - where our organization can make business decisions on the allocation of our limited resources, without examining how those decisions effect the supply and demand of our resources. You do know about those resources? Like money, people, and time?

Developers: Yea, we don't need any that mumbo jumbo microeconomics that we all learned in school, since we didn't pay attention in that boring the statistics and probability class that tried to teach us that all variables on a project are actually random variables and we should to know something about their behaviour in the future if we're going have a hope in hell of ever managing this project in the presence of uncertainty about those values.

Project Manager: What's that smell? Maybe we'd better start rearranging the deck chairs on our ship here real soon, cause I smell an Iceberg getting closer.

No project can be managed to successful closure in the absence of steering targets defined at periodic intervals for the expenditure of cost, schedule, and technical performance. Knowing what those steering targets should be requires estimating their values, then measures the actual values to develop the needed steering signal - the variance between plan and actual.

The only way out of the need to estimate those intermediate steering targets is to straight line the budget, schedule, and needed technical performance - from start to end, then measure the actual performance. 

Like the intended route of the Titanic, our project does not proceed in a straight line, so that idea is a non-starter. And like the Titanic, our project cannot confuse the intended speed with the actual speed, just like we can't confuse the budget - the total planned crossing time - with the actual cost - the actual total crossing time.

Titanic-Route

Without those pesky intermediate targets to steer toward - those targets created by estimating the needed cost, needed scheduled arrival date, and, needed capabilities on the needed date for the needed cost. We're managing the project Open Loop, driving in a straight line. Never knowing what will pop up in front of our path. 

Say good bye to Kate Leonardo, you're gonna get wet.

† Full attribution for the inspiration for this post comes from the very useful blog by Gene Hughson

Related articles Staying on Plan Means Closed Loop Control How Not To Make Decisions Using Bad Estimates Control Systems - Their Misuse and Abuse More Than Target Needed To Steer Toward Project Success Why Project Management is a Control System
Categories: Project Management

Systems Thinking and Capabilities Based Planning

Tue, 08/19/2014 - 04:23

The term Systems Thinking is many times used in vague and unspecified ways to mean think about the system and all will emerge in a way needed to produce value. 

Systems Thinking is a term toosed around many times with little regard for what it actually means and its relationship to Systems Engineering and Engineered Systems.

But systems thinking is much more than that. Systems thinking provides a rigorous way of integrating people, purpose, process and performance and: †

  • relating systems to their environment.
  • understanding complex problem situations
  • maximising the outcomes achieved.¬†
  • avoiding or minimising the impact of¬†unintended consequences.
  • aligning teams, disciplines, specialisms and¬†interest groups.
  • managing uncertainty, risk and opportunity.

†  "How Systems Thinking Contributes to Systems Engineering," INCOSEUK, Z7, Issue 1.0, March 2010.

Related articles A Breathtaking Paper Positive Deviance
Categories: Project Management

Why Is It Hard To Manage Projects?

Mon, 08/18/2014 - 05:36

In the absence of a control system that provides feedback to the progress to plan, the project is just wandering around looking for what Done looks like. The notion of emergent requirements is fine. The notion of emergent capabilities is not.

If we don't know what capabilities are needed to fulfill the business plan or fulfill the mission need, then we're on a Death March project. We don't know what value is being produced, when we will be done, or how much this will cost when we're done.

This is the role of the project control system. Without a control system there is no way to use feedback to steer the project toward success.

Control systems from Glen Alleman So when we hear we can make decisions wihout estimating the impact of those decisions on the furture outcomes of the project, we'll know to call BS. First not knowing this impact on the decision making process violates the principle of Microeconomics and second there is no way to close the loop to generate a variance signal needed to steer the project to success. Related articles Staying on Plan Means Closed Loop Control Concept of Operations First, then Capabilities, then Requirements Delivering Needed Capabilities What Do We Mean When We Say "Agile Community?" More Than Target Needed To Steer Toward Project Success Getting to done!
Categories: Project Management

The Purpose Of Guiding Principles in Project Management

Thu, 08/14/2014 - 16:02

Five principles

A Guiding Principle defines the key criteria for making decisions about the application of a project's Practices and Processes. The Principles provide the project with the foundation to test the practices and processes in pursuit of the project's goals in the most timely and cost-effective way while still meeting essential requirements of business outcomes or mission accomplishment.

In the absence of Principles, the Practices and Processes - while possible the rights one - have no way of being tested to assure they are producing actionable information for the management of the project. 

The common lament of we could be spending time and effort doing something more useful, ignores the fact that those  useful things need to be guided by a higher structure - a holistic structure - of exchanging cost for value. The questions should be are the practices and processes we are applying to this project the proper ones to maximize the efficacy of our funding?

These five principles are the foundation of project success. Success means - in the simplist terms - On Time, On Cost, On Value. Time and Cost are easily defined, Value needs another layer for it to be connected with Time and Budget.

What is Strategy

One approach for Value to to connect the outcomes of the project with the¬†Strategy for the business or the mission.¬†Strategy is creating fit among a company‚Äôs activities. The success of a strategy depends on doing many things well ‚Äď not just a few. The things that are done well must operate within a close nit system. If there is no fit among the activities - in this post, the project management activities - there is no distinctive strategy and little to sustain the project management practices and processes. Project Management then reverts to the simpler task of overseeing independent functions. When this occurs operational effectiveness determines the relative performance of the project management activities and the results of the project itself.¬†

Improving operational effectiveness is a necessary part of management, but it is not strategy. In confusing the two, managers will be unintentionally backed into a way of thinking about competition that drives the business support processes (IT) away from the strategic support and toward the tactical improvement of operational effectiveness.

The concept of fit among functions is one of the oldest ideas in strategy. Gradually, it has been supplanted with new concepts of core competencies, critical resources and key success factors. Fit is far more critical to the success of the project management System. Strategic fit among the project management Practices and Processes and the business processes in which the project is deployed is fundamental not only to competitive advantage but also to the sustainability of that advantage. 

This is the fundation of success for Project Based Organizations

The mechnism for creating this Fit is the Programmatic Architecture of the project. This architecture is the same term used for technical architecture. It is the form of the project, in the same way it is the form of the product or service.

The Five Principles That Establish Programmatic Architecture

These Five Principles and their Practices are...

Principles and Practices of Performance-Based Project Management¬ģ from Glen Alleman Related articles What Is Strategy? Elements of Project Success Why Project Management is a Control System Creating Effective Mission Statements That Have Meaning and Function Performance Based Management Principles First, Then Practice Moving EVM from Reporting and Compliance to Managing for Success Project Maxims How To Make Decisions
Categories: Project Management

Seven Principles of Agile Software Development in the US DOD

Wed, 08/13/2014 - 23:36

The Software Engineering Institute is a FFRDC (Federally Funded Research and Development Center). An FFRDC, IDA, is a client.

SEI is focused on helping the DOD improve the development of software.

Here are Pod Casts of the Principles of Agile Development of software in the DOD

  • First Principle¬†- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.‚ÄĚ
  • Second Principle - Welcome changing requirements, even late in development
  • Third Principle - Delivering working software frequently‚ÄĚ
  • Fourth Principle - Business people and developers must work together daily throughout the project.
  • Fifth Principle - Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
  • Sixth Principle - The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
  • Seventh Principle - Working software is the primary measure of progress
Related articles Is Your Organization Ready for Agile? Three Kinds of Uncertainty About the Estimated Cost and Schedule Can Enterprise Agile Be Bottom Up? What Do We Mean When We Say "Agile Community?" Studies, Science, Cybersecurity & Saddam: $888.8M to IDA for its 3 US FFRDCs from 2014-2018.
Categories: Project Management

The Ruckus About DDSTOP Post

Wed, 08/13/2014 - 18:03

OpinionAwhile back I posted about Don't Do Stupid Things On Purpose (DDSTOP). This caused some comments about this being a very Theory-X management approach. The notion of Don't Do Stupid Things on Purpose comes from observinig people DSTOP with other peoples money.

Many might say, people have to experiment, try thing out, test the waters. Yes this is true, but who pays for that testing, trying, experimenting? Is there budget for that in the project plan? May be that this is actually an experimental project and the whole point of the project is to do stupid things on purpose to see what happens. 

I wonder if the experimental work being paid for by the customer were worded like that if it would sound so clever?

Here's some clarity and a few examples of DSTOP in recent years.

  • Install CA's Clarity (a very expensive project management and project accounting system).
    • Apply Earned Value to a large ($250M) Enterprise IT project. Project gets in trouble, we come on board to perform¬†triage and discover that the Program Management Office has been copying ACWP - the Actual Cost of Work Performed - to BCWP - the Budgeted Cost of Work Performed - the Earned Value - then reporting to senior management that everything is going fine.
    • Instead of actually measuring physical percent complete to compute BCWP, they simplied copies the cost of the budgeted work, hiding the actual process
    • That's DSTOP
  • Install TTPro as a defect tracking and help desk ticketing system,
    • Communicate verbally most of the defect repairs dome in development.
    • Lose the traceability between the defect and the fix, so the QA staff can't trace the defects back to their rest coverage suite
    • That's DSTOP
  • Plan the development of several 100 million $ of flight avioncis upgrades for an aircraft that has been upgraded in the past.
    • Build the Integrated Master Schedule around the past performance activities - good idea
    • Resource load the IMS from past performance - good idea
    • Discover that the cost and schedule don't fit inside the stated needs of the customer, so¬†dial the work durations and assigned labor loads to fit the¬†price to win for the RFP
    • Get awarded the control, go over budget, and show up late after 12 months of work, get contract canceled
    • That's DSTOP

So is it Theory X to ask those working on the project and managing the project to stop and think about what they are doing, what decisions are being made - and assess the impact of those decisions? Or should those entrusted with the customers money just go exploring, trying out ideas with the hope that something innovative will come out of it?

When we're assumed to be the stewards of other people's money, they should expect us to behave as those stewards. This means we make decision about the use of that time and treasure is ways that are informed by our experience, skills, and governance model. Doing otherwise means we're not the right people to be spending our customers money, or our customer has a lot of money to spend on us to become the right people they should have hired to spend their money.

Related articles In Earned Value, Money Spent is Not a Measure of Progress! What Do We Mean When We Say "Agile Community?"
Categories: Project Management

Staying on Plan Means Closed Loop Control

Tue, 08/12/2014 - 00:19

Screen Shot 2014-08-11 at 5.03.33 PMFor most projects showing up on or near the planned need date, at or near the planned cost, and more or less with the planned capabilities is a good measure of success. Delivering capabilities late and over budget is usually not acceptable to those paying for our work.

So how do we do this? Simple actually.

We start with a Plan. Here's the approach to Planning and the resulting Plan.

Planning constantly peers into the future for indications as to where a solution may emerge. A Plan is a complex situation, adapting to an emerging solution. 
- Mike Dwyer, Big Visible

The Plan tells us when we need the capabilities to produce the needed business value or accomplish the mission. The Plan is a strategy. This strategy involves setting goals, determining actions to achieve the goals, and mobilizing resources to execute the actions. The strategy describes how the ends (goals) will be achieved by the means (resources) in units of measure meanigful to the decision makers.

Strategy creates fit among a firms activities. For Enterprise IT, this fit is defined by the relationships between the needed capabilities delivered by the project. The success of a strategy depends on doing many things well ‚ÄĒ not just a few.

The things that are done well must operate within a close nit system. If there is no fit among the activities, there is no distinctive strategy and little to sustain the strategic deployment process. Management then reverts to the simpler task of overseeing independent functions.

When this occurs operational effectiveness determines the relative performance of the organization. ["What is Strategy,‚ÄĚ M. E. Porter, Harvard Business Review, Volume 74, Number 6, pp. 61‚Äď78.]

As successful Plan describes the order of delivery of value in exchange for cost, the inter-dependencies between these value producing items, and the synergistic outcomes from these value producing items working together to meet the strategy.

With the Plan in hand, we can ask and answer the following questions:

  • Do we know what Done looks like in units of measure meaningful to the decision makers?
  • Do we have a strategy for reaching done, on or near the need date, at or near the budget?
  • Do we have the resources we need to execute that strategy?
  • Do we know what impediments we'll encounter along the way and how we're going to handle them?
  • Do we have some means of measuring our progress along the way to provides the confidence we'll reach done when we expect to?¬†

This Post Answers the Last Question

The example below is from our cycling group. The principles are the same for projects. We have a desired outcome in terms of date, cost, and technical performance. These desired outcomes have some end goal. A budget, a go live date, a set of features or capabilities needed to fulfill the business case. 

Along the way we need to take corrective actions when we see we are falling behind. 

How did we know we were falling behind? Because we have a desired performance at points along the way, that we compare our actual performance to. The difference between our actual performance and the desired performance, creates an "error signal" we can use to make adjustments.

Out thermostat does this, our speed control on our car does this, the Close Loop Control systems used for managing our project does this. So replaces the cycling example with writing software for money. The Peleton for the desired performance of our work. In the presentation below, ignore the guy in the Yellow Jersey at the end. Turns out he's a Dopper and an all around bad person to his fellow riders and fans.

The simple problem of schedule performance indices from Glen Alleman So let's look at a project example using the analogy of our cycling group, ignoring Lance.
  • We have a goal of riding a distance in a specific time. This can be a training ride, a century, or a Grand Fondo (timed distance for record).
  • We have instruments on the bike. Strava on the smart phone. Gamin on the bars. Both keeping track of instantaneous speed, time moving, total time. As well an average time over the distance.
  • We know, because we've done this route A 100 times before, or we know because we looked at the coure map, or we know because we have talked about the planned distance for the day - about how fats we need to ride - on average - to get back to the drive on a planned time.
  • Say we're out for our Saturday ride, which is usually a 50 to 65 mile loop from the driveway in Niwot Colorado to Carter Lake south of Fort Collins.
  • As a group we agree our average pace will be 20 MPH. Everyone has some way of measuring their average and instantaneous speed.
  • Over the course, it's never flat, some climbs and descents, change the flat land speed, but the average needs to stay at 20 MPH.¬†
  • When one or more¬†drop off the back, I'm usually one of those, we know what are average is. And instinctively we know how much faster we need to ride to catch up -¬†pick up the pace.
  • But if we were actual racers riding solo -¬†time trial or Triathlon, we'd look at our Garmin to see if we're going fast enough to¬†get back on pace, and come in under our target time.

This example can be related to a project. 

  • We have a target for the end ‚ÄĒ a target set of capabilities, with a need date, and a target budget
  • We have targets for all the intermediary points along the way ‚ÄĒ capabilities over time, budget over time.
  • We know our¬†pace ‚ÄĒ how fast to we have to go, how much cost can we absorb, to make our goal of delivering the needed capabilities on the needed date, for the needed budget.
  • We know the gap between our¬†pace and our¬†needed pace¬†to stay on track ‚ÄĒ with an intermediate desired performance, budget, number of features delivered, stated capabilities ready to be ¬†used, and the actual measures of these, we can develop a¬†variance that is used to product an error signal that is used to steer to the project. This is the feedback loop. The closed loop control system we need to keep the project on plan.
  • From that¬†variance we know how much faster we need to go to arrive on time.

This is Close Loop Control

  • Have a target for the end and we have intermediate targets along the way. These intermediate targets are the feedback points we use to assess progress to date
  • Measure the actual value of whatever variables we need to provide visibility to the project's performance. This can be cost, schedule, performance. But it can be other attributes of the project. Customer acceptance. Market place feedback. Incremental¬†savings.
  • Determine the variance between the plan and the actual.
  • Take corrective action to close the gap to get back on target ¬†or get within the variance tolerance.
  • Repeat until project ends.

You're cruise control does this about every 10 milliseconds. You Nest thermostat does this slower, but still less than a minute. To know how often you need to sample your progress against plan, answer this question

How long are you willing to wait before you find out you're late? Sample at ¬Ĺ that time.

This is called the Nyquist Rate, one of the starting point for all the process control software I wrote in my youner days for flying and swimming machines. But it's a good question to ask on all projects as well.

Related articles Is There Such a Thing As Making Decisions Without Knowing the Cost? Time to Revisit The Risk Discussion Can Enterprise Agile Be Bottom Up? Process Improvement In A Complex World Why Project Management is a Control System If you want to pretent you're a Pro, then starting acting like one Control Systems - Their Misuse and Abuse Seven Immutable Activities of Project Success More Than Target Needed To Steer Toward Project Success
Categories: Project Management

Quote of the Day

Sun, 08/10/2014 - 18:27

"You cannot have an execution culture without robust dialog - one that brings reality to the surface through openness, candor, and informality.
This is called "truth over harmony"

in Execution: The Discipline of Getting Things Done, Larry Bossidy and Ram Charan

Related articles Practices without Principles Does Not Scale The Need for Strategy How to Manage in the Presence of Uncertainty
Categories: Project Management

More Than Target Needed To Steer Toward Project Success

Sat, 08/09/2014 - 15:49

There is a suggestion that only the final target of a project's performance is needed to steer toward success. This target can be budget, a finish date, the number of stories or story points in an agile software project. With the target and the measure of performance to date, collected from the measures at each sample point, there is still a missing piece needed to guide the project.

With the target and the samples, no error signal is available to make intermediate corrections to arrive on target. With the target alone, any variances in cost, schedule, or techncial performance can only be discovered when the project arrives at the end. With the target alone, this is an Open Loop control system.

Control systems from Glen Alleman Pages 27 and 28 show the difference between Open Loop control and Closed Loop control of a notional software development project using stories as the unit of measure. In the figure below (page 27), the cummulative performance of stories is collected from the individual performance of stories over the projects duration. The target stories -  or budget, or some other measure - is the final target. But along the way, there is no measure of are we going to make it at this rate?  An Open Loop Control System
  • Is a non-feedback system, where the output ‚Äď the desired state ‚Äď has no influence or effect on the control action of the input signal ‚ÄĒ the measures of performance are just measures. They are not compared to what the performance¬†should be at that point in time.
  • The output ‚Äď the desired state‚Äď is neither measured nor ‚Äúfed back‚ÄĚ for comparison with the input ‚ÄĒ there is not an intermediate target goal to measure the actual performance against. Over budget, late, missing capabilities are only discovered at the end.
  • Is expected to faithfully follow its input command or set point regardless of the final result ‚ÄĒ the planned work can be¬†sliced into small chunks of equal size - this is a huge assumptions by the way - but the execution of this work must also faithfully follow the planned productivity. (See assumptions below).
  • Has no knowledge of the output condition ‚Äď the difference between desired state and actual state ‚Äď so cannot self-correct any errors it could make when the preset value drifts, even if this results in large deviations from the preset value ‚ÄĒ the final target is present but the compliance with that target along the way is missing, since there is no intermediate target to steer toward for each period of assessment - only the final.
Screen Shot 2014-08-09 at 7.46.27 AM There are two very simplifying assumptions made in the slicing approach sugegsted to solve the control of projects: 
  • The needed performance in terms of stories or any other measure of performance are linear and of the same size - this requires decompsong the¬†planned¬†work for each period to nearly identical sizes, work efforts, and outcomes.
  • The productivity of the work performed is also linear and unvarying - this require zero defects, zero variance in the work effort, and sustained productivity at the desired performance level.
Fulfilling these assumptions before the project starts requires effort and the assumptions about the homogeneity of the planned production, the homogeneity of the work effort, and the homogeneity of any defects, rework, or changes in plan would require near Perfect planning and management of the project. Instead, the reality of all project work is the planned effort, duration, outcomes, dependencies, and cost are random variables. This is the nature of the non-stationary stochastic processes that drive project work. Nothing will turn out as planned during to uncertainty. There are two types of uncertainty found in project work:
  • Irreducible Uncertainty - this is the¬†noise of the project. Random fluctuations on productivity, technical performance, efficiency, effectiveness, risk. These cannot be reduced. They are Aleatory Uncertainties.
  • Reducible Uncertainty - these are¬†event based uncertainties that have a probability of occurring, have a probability of the consequences, and have a residual probability that when fixed will come back back again.

Irreducible Uncertainty can only be handled with Margin. Cost margin, schedule margin, technical margin. This is the type of margin you use when you drive to work. The GPS Navigation system says it 23 ninutes to the office. It's NEVER 23 minutes to the office. Something always interferes with our progress.

Reducible Uncertainty is handled in two way. Spending money to buydown the risk that results from this uncertainty. Management Reserve (budget reserve and schedule contingency) to be used whenm soemthnig goes wrong to pay for the fix when the uncertainty turns into reality.

The next figure (page 28) shows how to manage in the presence of these  uncertainties, by measuring actual performance against the desired performance at each step along the way.

Screen Shot 2014-08-09 at 8.03.15 AM

In this figure, we measure at each assessment point the progress of the project against the desired progress - the planned progress, the needed progress. This planned, desired, or needed progress is developed by looking at the future effort, duration, risk, uncertainty - the stochastic processes that drive the project - and determining what should be the progress at this point in time to reach our target on or before the need date, at or below the needed cost, and with the needed confidence that the technical capabilities can be delivered along the way?  This is closed loop control.

The planned performance, the needed performance, the desired performance is developed early in the project. Maybe on day one, more likely after actual performance has been assessed to calibrate future performance. This is called Reference Class Forecasting. With this information estimates of the needed performance can then be used to establish steering targets along the way to completing the project. These intermediate references - or steering - points provide feedback along the way toward the goal. They provide the error signal needed to keep the project on track. They are the basis of Closed Loop control. 

In the US, many highways have rumble strips cut into the asphalt to signal that you are nearing the edge of the road on the right. They make a loud noise that tells you - hey get back in the lane, otherwise you're going to end up in the ditch.

This is the purpose of the intermediate steering targets for the project. When the variance between planned and actual exceeds a defined threshold, this says hey, you're not going to make it to the end on time, on budget, or with your needed capabilities if you keep going like this.

Ditch 03[1]

Kent Beck's quote is...

Optimism is the disease of software development. Feedback is the cure.

 

This feedback must have a reference to compare against if it is to be of any value in steering the project to a successful completion. Knowing it's going to be late, over budget, and doesn't work when we arrive at late, over budget, and not working is of little help to the passengers of the project.

Related articles Indicators of project performance provide us with "Steering Inputs" Seven Immutable Activities of Project Success Why Project Management is a Control System The Use and Misuse of Little's Law and Central Limit Theorem in Agile Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Slicing Work Into Small Pieces How To Assure Your Project Will Fail Control Systems - Their Misuse and Abuse Getting to done!
Categories: Project Management

Quote of the Day

Fri, 08/08/2014 - 22:31

Strategy without tactics is the slowest route to victory
Tactics without strategy is the noise before defeat.

‚ÄĒ Sun Tzu

Every time you hear about some conjectured great new idea on how to solve a vexing problem, ask what's the actual problem to be solved, what's the root cause of that problem, what domain is this problem found in and what domain is this problem already solved in, and finally ask what's your strategy for assuring that your solution will actually result in a solution that doesn't break something else, violate a business principle, and create an obligation that you didn't think of because you were too busy admiring your cleaver idea?

 

Categories: Project Management

Process is King

Thu, 08/07/2014 - 18:35

The notion of self-directed development teams has a range of applicable domains. Much of the rancor around agile development these days is about how to apply the core principles of agile software development. Do we need estimates? What's the role of business process in the development life cycle? How are capabilities and requirements elicited? Who has what decision rights for what decisions? How can we made these decisions and what information is needed in order to make the decisions?

Guy Strelitz's post has got me thinking about the spectrum of the world called agile. Here's my take on his diagram. Working in a domain where we're spending other people's money, lots of other people's money, the Winging it approach is simply not accepted. The Kanban approach doesn't either because the inter-dependencies between the backlog items it tight, so picking the next thing off the blog log based on business value may not be possible, since some pre-condition may need to be fulfilled before a higher value item can be started. Softwarr development is not production in our domain. Kanban is a production flow management system, no matter how twisted the logic of the Kanban software advocates make it out to be.

Scrum is a powerful approach to emergent requirements. With those requirements anchored to Needed Capabilities. Capabilities that all have to be in place for the system to be called ready for Go Live. Some more formality is needed as governance and regulatory paradigms are encountered.

Finally we arrive at the Enterprise model of software development. The firm depends on the software system for revenue. PayPal depends on the system for revenue, but not in the way an insurance company does. Or a gas pipeline process control system does. 

But at the same time, agile can contribute to not only increasing the probability of project success, but also deal with the emerging requirements traceable to the need capabilities.

Screen Shot 2014-08-06 at 11.37.15 AM

Process is King

So not to the point. In that agile enterprise paradigm, the mission critical aspects of the software system demand assuance that the released software is not only Fit for Purpose and it is Fit for Use. That is, the software does what it is supposed to do, in a way it is supposed to work. 

One of the critically important process of any enterprise software system is the Change Control (CC) and Release Management (RM) process. The software system is a corporate asset and must be treated as such. This asset is carried on the General Ledger as an asset. A capital investment, governed by the rules of accounting for capital assets. That's essentially the definition of enterprise. 

In this enterprise paradigm, the control of these assets starts with CC and RM. Here's a high level flow of how this corporate asset is managed. In this example development occurs in the lower left. The CC and RM process is post development. This development business rhythm can be weekly, monthly, possibly even daily. But once the software is ready for release to production, this is a possible process. 

The key here is separation of concerns. The developers of enterprise software our not the approvers of the release of that software, nor are they the involved in the QA, UAT, and Performance Assessment of that software.

Screen Shot 2014-08-06 at 11.33.30 AM

So this is the separation from the activities on the left of the top diagram to those on the right. When some suggests a new idea, or has read a book about a new idea and wants to discuss it - ask where on the spectrum of the top diagram they work, where they think their idea would fit in.

In the End

Without first starting with a domain, context, framing assumptions around governance, established decision rights any suggested process has no home for being tested against reality.

Related articles Performance Based Management Agile Project Management Kanban is the New Scrum Can Enterprise Agile Be Bottom Up? Agile Paradigm The Myth of Incremental Development
Categories: Project Management

Quote of the Day

Wed, 08/06/2014 - 14:38

No data hath meaning apart from their context. ~unknown

Related articles How to Forecast the Future Failure is NOT an Option!
Categories: Project Management

Quote of the Day

Tue, 08/05/2014 - 16:34

A point of view can be a dangerous luxury when substituted for insight and understanding.
~ Marshall McLuhan

Categories: Project Management

What Do We Mean When We Say "Agile Community?"

Mon, 08/04/2014 - 17:29

In a recent Skype conversation around agile, estimating, Little's Law and the #NoEstimate hashtag, the term agile community was used. My first reaction was whose agile community? The community of sole contributors? The community of $1B weapons systems and all in between?

My thoughts go back to the presentation below. There is a spectrum of project management processes built around agile. My experience starts with 5. Literally 5, since I have time in that aircraft. My software development management experience goes all the way to the end. And aircraft experience to 25.

Paradigm of agile project management from Glen Alleman So when I hear the agile community which one is it? The recent Agile Conference looks like it was attended by sole contributors or small team members. But there are other agile communities where I work

And guideance for deploying agile

So Now Back To The Core Issues

If you're a sole contributor and have a customer sitting near by, estimating you cost, schedule, and technology outcomes is likely of little value. If you're in the other end, say the flight avionics systems for the 777, then the level of rigor, formality, reporting is different. Both use agile. Not all in the same way, but both write code using the principles of agile development

12 agile principlesNo credble management process would or should object to these principles and practices. Do to so means Doing Stupid Things on Purpose. So many of the motivators for not doing something are actually bad management. Let's not estimate, because estimates are misused is my favorite DDSTOP example.

Here's an example of how to connect the dots between these principles and practices in a more formal business management process - in this case Earned Value Management. 

Ev+agile=success (final v2) from Glen Alleman

So when we hear the agile community and those representing the agile community which community is that? 

There is a crass American term used in our domain.

When you see dysfunction, see something you don't understand, or see something that is counter to your paradigm - Follow the Money.

This is the basis of microeconomics of writing software for money. What is considered a waste or even evil in one domain is a critical success factor in another domain.

Ask some simple questions to establish this domain:

  • What's the¬†Value At Risk?¬†
  • Are you subject to any governance process?
  • Is this project considered mission critical in any way? Project's that are not mission critical have little need to be successful on time, on budget, with the needed capabilities.

In The End

Can we have any meanigful disucssion about any topic in the absence of a domain and context? Especially when that topic is driven by Value at Risk, Governance, and business processes?

I'd say it is incumbent on those making a suggestion for example

No Estimates

To show in what domain this statement is applicable, how we would recognize its applicability outside the the domain of those making the suggestion, how we could test the suggestion to see if it is applicable, and most important what are the conditions that allow the suggestion to work in those domains? 

  • How can decisions be made in the absence of knowing the impact of those decisions? This is a violation of the principles of microeconomics.
  • How can we spend other peoples money and not inform them about the probability of the total cost, delivery date, and confidence in delivering the needed capabilities?
  • How can we plan for needed capacity in the absence of knowing what¬†Done looks like in some unit of measure meaningful to the decision maker - not just the solution provider?
Related articles Agile and the Federal Government Agile as a Systems Engineering Paradigm Can Enterprise Agile Be Bottom Up? What Software Domain Do You Work In? More #NoEstimates Using Agile Effectively in DoD Environments Is Your Organization Ready for Agile? Domain and Context Are King, Then Comes Process and Experience
Categories: Project Management