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!
Software Development Blogs: Programming, Software Testing, Agile Project Management
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!
Before you begin a thing remind yourself that difficulties and delays quite impossible to foresee are ahead. You can only see one thing clearly, and that is your goal. Form a mental vision of that and cling to it through thick and thin.
‚ÄĒ Kathleen Norris
And when they are impossible to see we need margin and reserve to protect our project from them. This margin is for the irreducible risks and the reserve is for¬†buying down the reducible risks. Both irreducible (aleatory) and reducible (epistemic) uncertainties can be modeled for all projects. This is the role of risk management and project. To NOT model these uncertainties is to ignore them. To ignore them is to say to those providing the money that you're not following Tim Lister's advice...
Risk Management is how Adults manage projects
As well when you begin a thing remember another important quote...
Measurement is the first step that leads to control and eventually to improvement. If you can‚Äôt measure something, you can‚Äôt understand it. If you can‚Äôt understand it, you can‚Äôt control it. If you can‚Äôt control it, you can‚Äôt improve it. ‚Äē H. James Harrington
So if we're going to start a job and don't have an assessment - to some level of confidence - of how long it will take, how much it will cost, and what we will be capable of delivering when we get to the end of the money and the time - it is very likely that those paying for our work will be very disappointed in our efforts.
When we here that we can make decisions in the absence of knowing the probabilistic cost, schedule, and likelihood of producing the needed capabilities, think back to the two quotes above. And consider the conjectures below that requires us to ignore those quote and instead follow those statements in the absence of any evidence they are applicable outside of the¬†Value at Risk being low enough that those providing the money don't really care if it's all a loss.
‚Ä† Orginal post from Mark Anderson's email from ExecuNet, 9/14/2014Related articles Uncertainty is the Source of Risk The World of Probability and Statistics How to Deal With Complexity In Software Projects? Both Aleatory and Epistemic Uncertainty Create Risk Time to Revisit The Risk Discussion
With all the speculation on what went wrong with the ACA site and all the agile pundits making statements about how agile could have saved the site, here's some actual facts beyond all the opinions - that Daniel¬†Patrick¬†Moynihan would remind us...
Every man is entitled to his own opinion, but not his own facts
The Key Findings are
So when we hear¬†
Think in what domain, with what value at risk, with what complexity of project, and what business process in which these could possibly be applicable. In fact this goes back to the core of the agile manifesto. And when we hear "pure agile," Scrum Masters produce Scrum Slaves, Mob Programming, "we all want a seat at the table with equal voices, and many other "opinions," remember¬†Moynihan and ask for facts, domain, past performance, experience, and examples of success.
As agile starts to scale to larger domains and the government seeks better ways to develop software beyond the failed processes described above - what parts of this manifesto are applicable outside of a small group of people in the same room with the customer directing the work of the developers?
As my colleague (former NASA Cost Director) reminds our team¬†if you see something that doesn't make sense - follow the money.¬†In the case of ACA and in the case of the Work Shop outcomes above.Related articles Can Agile Be Integrated with Governance Based Development Processes? Agile Means ... Can Enterprise Agile Be Bottom Up? Agile as a Systems Engineering Paradigm How To Create Confusion About Root Causes Agile and the Federal Government Quote of the Day - Just a Little Process Check Sailing and Agile
In the software development world this might be characterized by a customer wanting a set of features to be delivered for a budget on a certain date so those features can be put to work earning back their cost.
Since the list of features is likely to needed to be developed in a specific order with varying costs, the question is¬†what features should be done first and what features down next.¬†
The traditional response from an agile developer is the define the¬†value of those features and produce them in that order. What is the unit of measure of value. That's rarely stated. But along with the¬†Value¬†is the cost of that value and other attributes of the development process. Risk, resource demand, inter dependencies between other features, inter dependencies between these features and external processes - the¬†externalities of all complex problems.
The formal discipline is this process is called Multi-Criteria Decision Analysis (MCDA). MCDA has the following elements:
The principles in these early papers and the continued development of multi-criteria decision making have now moved to nearly every domain where scarce resources, probabilistic outcomes, uncertainty of the impact of the decisions, and¬†value at risk is high enough to ask the question
What will be the outcome of this decision on the future of the processes, cost, technology, environment, or any other external domain?
So when we hear that
We have to wonder if these frameworks, investment models, and project management methods have come in contact with the reality of how business works. As Carl saying in a somewhat harsh manner
Extraordinary claims require extraordinary evidence. Carl¬†SaganRelated articles Positive Deviance 5 Questions That Need Answers for Project Success
Absolutely value is needed and is the focus of our work efforts. No customer is going to pay for a product or service that doesn't have the needed value. This value is usually in a unit of measure around a "capability" to do something for the that in turn solves a problem, generates revenue, enables another process to function.
Measures of Effectiveness to get the job done. Measures of Performance while getting the job done. The Technical Performance Measures of the underlying hardware, software, people processes that enable the job to get done at the right cost.
But this value is an¬†enabler.¬†The units of measure of the value are defined by the customer, not the provider. The¬†Marketing department of the provider may have suggestions about the value of the product or service, but it is the customer that confirms that value.
In doing the confirmation of Value, the buyer (internal or extermal customer) makes this assessment using a foundational principles of all business decisions...
Microeconomics is a branch of economics that studies the behavior of individuals and small impacted organizations in making decisions on the allocation of limited resources. Those limited resources to the buyer are:
The time value of money is then used by the buyer to enable another decision making process
ROI = (Value - Cost ) / Cost
So when we hear, we don't need to know the cost, that is we don't need to estimate the cots of producing the value, think again. This can only be true if the delivered value takes place in the presence of unlimited resources. That is we have all the time we need and no one really cares about the cost. That is the principle of microeconomics of business decision making is not in play.
As a final point. Budget is NOT Cost. Setting the budget, only sets the budget. The cost of the work is called¬†Actual Cost¬†and actual cost is generated by exchanging labor and materials for money. So setting the budget is needed. But setting the budget only says what the¬†expected¬†cost¬†might¬†be. If you're given an budget and an expected set of¬†Value outcomes, estimates of the confidence of delivering that¬†Value will be needed. Otherwise your budget is just a number, that will easily be¬†blown¬†before you delivery the needed capabilities on the needed date.
If asked¬†what should our budget be for the expected Value, then solving the ROI or Expected Monetary Value, or Value at Risk needs to take place. In order to do this for a decision about the future ROI, EMV, or VAR, we need to estimate both the¬†Cost and¬†Value - then manage the project that produces the¬†Capabilities¬†that deliver the¬†Value¬†toward both those cost and time variables. And of course those variables are random variables.
When it is stated in an work shop where the participants will learn about
Then those processes are not operating in a governance domain where microeconomics of product developments are in place. Can't say where they are operating, but it's not on this planet of a¬†for profit business. Or those proffering this approach have discovered a secret sauce that gets around the basic principles of all business -
Profit = Revenue - Cost of Goods Sold
The only place I know this principle is not in place, is here in Colorado, just outside of Fairplay, CO, is South Park.
Here in South Park, the local businessmen have a clever plan to get rich without be subject to microeconomics of making decisions about how to do that.
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?
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¬†
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.¬†
I 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.
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.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
"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
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.
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.
The 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
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
When I read about decision making processes like ...
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:
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.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?
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.
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 HughsonRelated 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
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: ‚Ä†
‚Ä† ¬†"How Systems Thinking Contributes to Systems Engineering," INCOSEUK, Z7, Issue 1.0, March 2010.Related articles A Breathtaking Paper Positive Deviance
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!
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
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
Awhile 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.
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?"
For 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.
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:
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.
This example can be related to a project.¬†
This is Close Loop Control
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
"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 CharanRelated articles Practices without Principles Does Not Scale The Need for Strategy How to Manage in the Presence of Uncertainty
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
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.
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.
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!
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?