Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/sources/6' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
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
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.
Syndicate content
Performance-Based Project ManagementÂź Principles, Practices, and Processes to Increase Probability of Success
Updated: 6 hours 46 min ago

Quote of the Day

Mon, 02/08/2016 - 21:17

They constructed ladders to reach to the top of the enemy's wall, and they did this by calculating the height of the wall from the number of layers of bricks at a point which was facing in their direction and had not been plastered. The layers were counted by a lot of people at the same time, and though some were likely to get the figure wrong  the majorly would got it right .... Thus, guessing what the thickness of a single brick was, they calculated how long their ladder would have to be. - Thucydides, The Peloponnesian War

So when you hear, we don't need to estimate to know when we're done, that willfully ignores all the naturally occurring variances and the event based variances in all our project work. The Greeks knew this, we need to heed their advice.

Categories: Project Management

Quote of the Day

Sun, 02/07/2016 - 03:56

One's originality comes in your inability to emulate your influencers - Dale Watson

Categories: Project Management

Agile at Scale - A Reading List (Update 9)

Sat, 02/06/2016 - 19:30

Screen Shot 2015-11-30 at 8.59.46 AMI'm working two programs where Agile at Scale is the development paradigm. When we start an engagement using other peoples money, in this case the money of a sovereign, we make sure everyone is on the same page. When Agile at Scale is applied, it is usually applied on programs that have tripped the FAR 34.2/DFARS 234.2 levels for Earned Value Management. This means $20M programs are self assessed and $100M and above are validated by the DCMA (Defense Contract Management Agency).

While these programs are applying Agile, usually Scrum, they are also subject to EIA-748-C compliance and a list of other DID's (Data Item Description) and other procurement, development, testing, and operational guidelines . These means there are multiple constraints on how the progress to plan is reported to the customer - the sovereign.

These programs are not 5 guys at the same table as their customer exploring what will be needed for mission success when they're done. These programs are not everyone's cup of tea, but agile is a powerful tool in the right hands of Software Intensive System of Systems for Mission Critical programs. Programs that MUST, deliver the needed Capabilities, at the Needed Time, for the Planned Cost, within the planned Margins for cost, schedule, and technical performance.

One place to start to improve the probability that we're all on the same page is this reading list. This is not an exhaustive list, and it is ever growing. But it's a start. It's hoped this list is the basis of a shared understanding that while Agile is a near universal principle, there are practices that must be tailored to specific domains. And one's experience in one domain may or may not be applicable to other domains. 

Like it says in the Scrum Guide. 

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

And since Scrum is an agile software development framework, Scrum is a framework not a methodology. Scrum of Scrums, Agile At Scale, especially Agile at Scale inside EIA-748-C programs has much different needs than 5 people sitting at the same table with their customer with an emerging set of requirements where the needed capabilities are vague until they appear.

One of the classes every aspiring grad student has to take is research methods. This class teaches the PhD hopefuls (I didn't make the cut and got a consolation prize of a MS), all about doing research and preparing to be a real scientist. A topic in this class is literature search. This makes sure that your cleaver idea of a research topic, in case your advisor hasn't gotten around at actually talking to you, has already been taken, researched, and solved. This is one problem in the physics world - you need an original idea. Replicating old ideas doesn't get you very far.

Here's a start of a literature search on merging Agile at Scale with Earned Value Management. I haven't gotten to the European and Far East journals yet. 

Slicing Work Into Small Pieces Agile Software Development in the DOD Technical Performance Measures What Do We Mean When We Say "Agile Community?" Can Enterprise Agile Be Bottom Up? How To Measure Anything Business Rhythm Drives Process Empirical Data Used to Estimate Future Performance Related articles
Categories: Project Management

The Dark Sides of Agile and Earned Value Management and Their Fixes

Thu, 02/04/2016 - 16:08

Both Agile development and Earned Value Management are coming together in the Federal Government. DOD and many Federal Civil agencies are adopting the use of Agile software development. At the same time, FAR 34.2 and DFARS 234.2 are flow down on procurement programs that implement Earned Value Management.  

I've written about to benefits of this before, Here's some thoughts on the Dark Side

EVM+Agile the darkside from Glen Alleman Related articles Agile Software Development in the DOD Seven Principles of Agile Software Development in the US DOD What Do We Mean When We Say "Agile Community?"
Categories: Project Management

Quote of the Day

Wed, 02/03/2016 - 23:37

It is a capital mistake to theorize before one has data - Sir Arthur Conan Doyel

Categories: Project Management

Quote of the Day

Wed, 02/03/2016 - 20:07

Winnie-the-Pooh read two notices very carefully, first from left to right, and afterwards, in case he had missed some of it, from right to left - A.A. Milne, Winnie-the-Pooh

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter
Categories: Project Management

How Do You Estimate Work That's Never Been Done Before?

Wed, 02/03/2016 - 18:09

This is a common lament in the #Noestimates community

We've never done this before, so how can we possibly estimate how long it will take?

Well the first question is has it actually never been done before, or is the real question is have YOU never done it before? If the work has truly never been done before by anyone, anywhere on the planet, then it's probably going to be hard to estimate. But if the solution has been done before, this brings up the big question for those paying to have the development done, why would they hire someone that has no prior experience providing solutions in the problem domain? 

Let's assume you have prior experience in the problem domain, but the solution is not readily at hand. This means the solution actually has to be engineered. This is the role of  the well developed process of producing the engineering basis of estimate.

Let's start with the notion of Reference Classes. Here's some databases of projects that can used as Reference Classes used to frame the boundaries of the estimating processes for what you may consider new and never before seen work, but in fact has been done by someone else.

  • Nederlandse Software Metrieken Association - www.nesma.org

  • International Software Benchmarking Standards Group - www.isbsg.org

  • Common Software Measurement International Consortium - www.cosmicon.com

Next is the notion that every graduate student in almost any discipline - mine was Physics - is taught in the first year of grad school. When you have an idea, go first and check that some one hasn't already solved the problem. This starts with a literature search. This is a simple problem to solve in 2016. It's called Google. In 1975 it required weeks is long days in the library looking through journals and books in the Physics Library UC Irvine. But before anyone says This is a new and innovative problem and I can't possibly estimate how long it will take. Do your homework and go see if that is actually the case.

When we hear - how can I possibly estimate what I haven't done before? There are more steps to go before answering I can't

  • Have you developed a process architecture for what you want done from this software? Is this process architecture in the form of some swim lane diagram?
  • Have the system elements been partitioned and their interfaces defined at the data and process level. This definition can be high level to assess coupling and cohesion issues that will drive up cost?
  • Have Use Case's been developed for the system functions? Have the common actors, processes, and data been identified?

This list goes on for awhile. But when I hear I can't possibly estimate something that I haven't done before, it begs the question ...

Do you know what Done looks like in units of measure meaningful to the decision makers?

No? then no wonder you can't put upper and lower bounds on any estimate of effort - you don't even know what the customer wants and most importantly you don't know what the units of measure are for what done looks like.

Go find those answers and them you'll have a clearer idea of what the problem is and possibly how to solve it.

Categories: Project Management

Awards Season

Wed, 02/03/2016 - 16:34

Screen Shot 2016-01-19 at 6.40.39 PM

Read the full article at CEOLEVEL

Categories: Project Management

NOT Negotiating Estimates is Example of Bad Management (Update)

Fri, 01/29/2016 - 22:03

A recent Blog post used an example of negotiated estimates between the developers and management. In the example buying a car is used and compared to negotiated the cost of software development. The car was an example of knowing information about what was being negotiated and the software was a example of not knowing what was needed to produce an outcome.

The notion that in the software business we don't know or can't know what the cost, schedule, and outcomes are before we reach the end is sadly misinformed. One of my colleagues - a former NASA cost director - has three reasons projects go over budget, get behind schedule and don't produce the needed benefits:

  • We couldn't know - it was a true science project - inventing new physics
  • We didn't know - because we were too lazy to do our home work, and come up with some assessment of what it could cost
  • We don't want to know - because if we knew we'd never start the project, or we'd cancel the project now that we know

So let's pursue the car negotiation versus software negotiating on what something will cost a bit further

When negotiating the purchase of a car, the dealer starts with a price based on facts. The price paid at wholesale, the cost of money for flooring the car until it's sold. The buyer of the car usually comes equipped with facts as well. Edmunds pricing, Consumer Reports pricing, and similar sources of cost, margins, dealer incentives, local market conditions.

When the negotiations are successful, when there is a mutual beneficial outcome between the two parties - there is no asymmetric negotiating  position. For the dealer, he moves a car, stops paying on the 90 day flooring note needed to put the car on the lot, and the buyer gets the car at an acceptable cost. 

If we accept that estimates are for the business to make decisions more often than they are for developer decision, then facts are needed on both sides for a negotiation to have any mutual beneficial outcome for the business and those provided value to the business in exchange for the cost of that value.

When there is no factual basis of estimate, those asking for the estimate - the business, and there is no basis on which the judge the estimate provided by those being asked - the developers - there is no foundation for a mutual beneficial outcome. The result is an asymmetric negotiation. Those with the money usually win.  

When negotiating the cost of software development effort between the person asking for an estimated cost and the developers providing the software, there is a similar process. When the developer says it will take 5 units of cost (hours, weeks, months) and those asking for the estimates say “I need it in 3” AND there is no basis of estimate for either 5 or 3, there is no means to actually negotiate and the result is those paying.

Those with the money have the final say on how much and when. The developers have no recourse, since they don't possess a credible counter offer showing that the real cost is 5. The developers are on the wrong side of an asymmetric negotiation. 

Until those being asked - the developers - come to the table with credible, verifiable, statistically sound estimates, this relationship between those asking and those providing will never change. Those providing the estimate - and consuming the money need to have a credible basis of estimate. Those providing the money also need to have some sense of what a credible estimate looks like. This removes the asymmetric relationship and creates a symmetric relationship on which to actually negotiate a mutually beneficial outcome.

This by the way is one source of dysfunction the #NoEstimates advocates love to use without ever stating what is the source of the dysfunction. The Dysfunction is the asymmetric relationship between the parties. The buyers have a target, the sellers are clueless if that  is a reasonable target - end of conversation.

Showing up with NO counter estimate to a requested number - is a self-inflicted wound in the negotiating business. The result is those with the money get to tell those without the counter estimate what to do and it turns into a lose-lose outcome. Then the developers blame the estimating process for the resulting dysfunction and wonder why the business no longer listens to them.

You asked me to do it for 5 and I have no counter offer, so you win and actually we all lose. Then blame the request for estimating for the dysfunction. 

It is conjectured by #NoEstimates advocates that removing the estimating process will fix the dysfunction (what ever that is). Of course making decisions in the presence of uncertainty requires knowing something about outcomes as a result of the decision. But without a starting point for the estimate on the part of those spending the money, the asymmetric negotiating position cannot be removed. This is the actual source of Bad Management and cannot be the fix, since the negotiation is one sided and those with the money prevail when there is no counter offer. 

This is like walking into the car dealer wanting to buy a car, with no understanding of the cost of the car you want - your the business. No Morhoeny Sticker. No web pricing. No nothing. And the dealer - the developers - doesn't tell you what the price of the car is either, because it's too hard, is waste of time, and believe they'll be held to the price they say.

Update

Gene Hughson added his voice to negotiating estimates

And I fixed the title to be less obtuse

Related articles Domain is King, No Domain Defined, No Way To Test Your Idea Some more answers to the estimating questions Start with Problem, Than Suggest The Solution How to Avoid the "Yesterday's Weather" Estimating Problem Incremental Commitment Spiral Model No Estimates Needs to Come In Contact With Those Providing the Money The Microeconomics of Decision Making in the Presence of Uncertainty Want To Learn How To Estimate? Estimating Software-Intensive Systems
Categories: Project Management

NOT Negotiating Estimates is Example of Bad Management (Update)

Fri, 01/29/2016 - 22:03

A recent Blog post used an example of negotiated estimates between the developers and management. In the example buying a car is used and compared to negotiated the cost of software development. The car was an example of knowing information about what was being negotiated and the software was a example of not knowing what was needed to produce an outcome.

The notion that in the software business we don't know or can't know what the cost, schedule, and outcomes are before we reach the end is sadly misinformed. One of my colleagues - a former NASA cost director - has three reasons projects go over budget, get behind schedule and don't produce the needed benefits:

  • We couldn't know - it was a true science project - inventing new physics
  • We didn't know - because we were too lazy to do our home work, and come up with some assessment of what it could cost
  • We don't want to know - because if we knew we'd never start the project, or we'd cancel the project now that we know

So let's pursue the car negotiation versus software negotiating on what something will cost a bit further

When negotiating the purchase of a car, the dealer starts with a price based on facts. The price paid at wholesale, the cost of money for flooring the car until it's sold. The buyer of the car usually comes equipped with facts as well. Edmunds pricing, Consumer Reports pricing, and similar sources of cost, margins, dealer incentives, local market conditions.

When the negotiations are successful, when there is a mutual beneficial outcome between the two parties - there is no asymmetric negotiating  position. For the dealer, he moves a car, stops paying on the 90 day flooring note needed to put the car on the lot, and the buyer gets the car at an acceptable cost. 

If we accept that estimates are for the business to make decisions more often than they are for developer decision, then facts are needed on both sides for a negotiation to have any mutual beneficial outcome for the business and those provided value to the business in exchange for the cost of that value.

When there is no factual basis of estimate, those asking for the estimate - the business, and there is no basis on which the judge the estimate provided by those being asked - the developers - there is no foundation for a mutual beneficial outcome. The result is an asymmetric negotiation. Those with the money usually win.  

When negotiating the cost of software development effort between the person asking for an estimated cost and the developers providing the software, there is a similar process. When the developer says it will take 5 units of cost (hours, weeks, months) and those asking for the estimates say “I need it in 3” AND there is no basis of estimate for either 5 or 3, there is no means to actually negotiate and the result is those paying.

Those with the money have the final say on how much and when. The developers have no recourse, since they don't possess a credible counter offer showing that the real cost is 5. The developers are on the wrong side of an asymmetric negotiation. 

Until those being asked - the developers - come to the table with credible, verifiable, statistically sound estimates, this relationship between those asking and those providing will never change. Those providing the estimate - and consuming the money need to have a credible basis of estimate. Those providing the money also need to have some sense of what a credible estimate looks like. This removes the asymmetric relationship and creates a symmetric relationship on which to actually negotiate a mutually beneficial outcome.

This by the way is one source of dysfunction the #NoEstimates advocates love to use without ever stating what is the source of the dysfunction. The Dysfunction is the asymmetric relationship between the parties. The buyers have a target, the sellers are clueless if that  is a reasonable target - end of conversation.

Showing up with NO counter estimate to a requested number - is a self-inflicted wound in the negotiating business. The result is those with the money get to tell those without the counter estimate what to do and it turns into a lose-lose outcome. Then the developers blame the estimating process for the resulting dysfunction and wonder why the business no longer listens to them.

You asked me to do it for 5 and I have no counter offer, so you win and actually we all lose. Then blame the request for estimating for the dysfunction. 

It is conjectured by #NoEstimates advocates that removing the estimating process will fix the dysfunction (what ever that is). Of course making decisions in the presence of uncertainty requires knowing something about outcomes as a result of the decision. But without a starting point for the estimate on the part of those spending the money, the asymmetric negotiating position cannot be removed. This is the actual source of Bad Management and cannot be the fix, since the negotiation is one sided and those with the money prevail when there is no counter offer. 

This is like walking into the car dealer wanting to buy a car, with no understanding of the cost of the car you want - your the business. No Morhoeny Sticker. No web pricing. No nothing. And the dealer - the developers - doesn't tell you what the price of the car is either, because it's too hard, is waste of time, and believe they'll be held to the price they say.

Update

Gene Hughson added his voice to negotiating estimates

And I fixed the title to be less obtuse

Related articles Domain is King, No Domain Defined, No Way To Test Your Idea Some more answers to the estimating questions Start with Problem, Than Suggest The Solution How to Avoid the "Yesterday's Weather" Estimating Problem Incremental Commitment Spiral Model No Estimates Needs to Come In Contact With Those Providing the Money The Microeconomics of Decision Making in the Presence of Uncertainty Want To Learn How To Estimate? Estimating Software-Intensive Systems
Categories: Project Management

Another Agile Myth

Thu, 01/28/2016 - 16:34

A popular Agile phrase goes like this.

...it's important to know what Not to build

This begs the question, who's building things that other people don't want? Where's the process for assessing what people want? Seems pretty obvious that if you're building thing that you shouldn't be building you're not doing a very good job of requirements management.

Software requirements are a weak link in the chain of software engineering technologies.  Requirements are usually incomplete and change at rates in excess of 2% per calendar month.  For many years one common definition of quality has been “conformance to requirements.”  However this definition ignores the fact that some requirements are hazardous or “toxic” and should not be included in software applications.  Since clients themselves may not realize the dangers of toxic requirements, software engineers have a professional and ethical responsibility to point out the hazards of dangerous requirements and ensure that they are safely eliminated.  An example of a “toxic requirement” is the famous Y2K problem which did not originate as a coding bug but rather as an explicit but dangerous user requirement.

Capers Jones, Vice President and CTO, Namcook Analytics LLC

So how is it decided if a requirement is toxic or not. Well it's pretty straight forward:

This is the role of a requirements elicitation and management process. One based on an actually process, not just some made up, some cockamany approach to writing things done on sticky notes and asking the next passing person what they think. An actual, true to life requirements engineering process. 

This starts with a simple concept:

A requirement is a statement that identifies a capability, characteristic, or quality factor for a system for it to have value and utility to a customer or user. 

If we don't know these capabilities are, their attributes, characteristics, or other factors are, we won't recognize them before the money runs out. Can we over specify the requirements? Perhaps we can. Can we under specify the requirements? It's done all the time to the detriment of the project. We need to find a way to specify the requirements in a sweet spot. Not too much, not too little. 

Research shows the average investment in requirements elicitation and management is 2% to 3% of the total project cost. Research also shows this is wholly inadequate for success and is one of the root causes of failure on any non-trivial project. This research shows that projects that expended 2% to 3% on requirements experienced a 80% to 200% cost overrun. Those projects that expended 8% to 14% on requirements elicitation and management experienced 0% to 50% cost overruns.

We must be crystal clear here. Requirements may emerge, but the needed capabilities at the needed time are a critical success factor for any project, no matter the domain. As Yogi reminds us. If you don't know where you're going, you might not get there.

I'm not going to tell you how to develop requirements,. There are many ways, starting with the guidance listed below and endless other books articles, and papers. But if there is a notion that requirements are not needed - let's let them emerge and we'll start coding to see what comes out - it's going to be a rough ride before the money runs out.

 

[1] The Requirements Engineering Handbook, Ralph R. Young, Artech House, 2004

[2] Requirements Engineering: A Good Practice Guide, Ian Sommerville and Pete Sawyer, John Wiley & Sons, 1997

[3] Succeeding with Agile: Software Development Using Scrum, Mike Cohn Addison-Wesley, 2010.

[4] Project Management the Agile Way: Making it Work in the Enterprise, John C. Goodpasture, J. Ross, 2010.

[5] Agile Estimating and Planning, Mike Cohn, Prentice Hall, 2006

[6] Agile Project Management for Government, Brian Wernham, Maitland & Strong, 2012.

Categories: Project Management

The Dark Sides and Agile and Earned Value Management and Their Fixes

Wed, 01/27/2016 - 18:16

Both Agile development and Earned Value Management are coming together in the Federal Government. DOD and many Federal Civil agencies are adopting the use of Agile software development. At the same time, FAR 34.2 and DFARS 234.2 are flow down on procurement programs that implement Earned Value Management.  

I've written about to benefits of this before, Here's some thoughts on the Dark Side

EVM+Agile the darkside from Glen Alleman Related articles Agile Software Development in the DOD Seven Principles of Agile Software Development in the US DOD What Do We Mean When We Say "Agile Community?"
Categories: Project Management

The Problem with #Noestimates

Tue, 01/26/2016 - 06:48

The notion of a balanced discussion of the topic of Not estimating work on agile projects has yet to produce any principles on which this can occur. The #NoEstimates advocates have not provided the principles by which a decision about how to best spend the customers money in the presence of uncertainty of the outcomes (Microeconomics of decision making) without estimating the impact of the decision. 

The one principle based suggestion is Slicing and is considered #Noestimates. But of course slicing is the basis of making an estimate by reducing the variances of the work into a narrow range. Then assessing the effort to produce similar work in the future. This depends on that future work being like the work in the past. This also assumes there are no emergent uncertainties that create risk to that work. Either naturally occurring uncertainties (aleatory) or event based uncertainties (epistemic).

As well, slicing is also standard practice in all credible Basis of Estimate processes used in all domains where a non-trivial amount of money is at risk.

Without a foundational set of principles to support the conjecture that decisions can be made without knowing the outcome of that decision, #Noestimates is a solution looking for a problem to solve. 

And there are many problems, starting with Bad Management, a variety of biases, cooking the books for political reasons, lack of experience, skill, and knowledge in estimating, poor understanding of risk management, and numerous other root causes of project difficulties and many times downright failure because the knowledge of who much something will cost, when it will be ready for use, and what actually will be produced is not available to the decision makers.

I'm headed to Florida this week for a conference where Agile and Earned Value Management Systems are the topic. I'm reminded by a NASA Cost Director colleague there are three reasons projects get over budget, behind schedule, and don't produce the expected outcomes:

  1. We couldn't know- it's a science project and we're inventing new physics
  2. We didn't know - we didn't do our homework
  3. We don't want to know - if we knew, we would cancel the project before it starts

To date no evidence has been put forward to show how to make a decision when spending other peoples money in the presence of uncertainty without estimating the impact of that decision so an informed choice can be made on how to proceed.

Related articles Who's Budget is it Anyway? Making Decisions In The Presence of Uncertainty Eyes Wide Shut - A View of No Estimates
Categories: Project Management

Project Management is a Closed Loop Control System

Sat, 01/23/2016 - 23:27

Without a desired delivery date, target budget, and expected capabilities, a control system is of little interest to those providing the money at business level. There is no way to assure those needs – date, budget, capabilities – can be met with the current capacity for work, efficacy of that work process, or budget absorption of that work. 

With a need date, target budget, and expected capability outcome, a control system is the basis of increasing the probability of success. These targets are the baseline to steer toward. Without a steering target the management of the project is Open Loop. There are two types of control systems

  • Closed Loop Control – where the output signal has direct impact on the control action.
  • Open Loop Control – where the output signal has no direct impact on the control action.

An Open Loop Control 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. In an Open-Loop control system the output – the desired state– is neither measured nor “fed back” for comparison with the input.  An Open-Loop system is expected to faithfully follow its input command or set point regardless of the final result. An Open-Loop system 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.

An Closed-loop Control System, is a feedback control system which uses the concept of an open loop system as its forward path but has one or more feedback loops between its output and its input. In Closed Loop control, there is a “feedback,” signal that means some portion of the output is returned “back” to the input to form part of the systems excitation.

Closed-loop systems are designed to automatically achieve and maintain the desired output condition by comparing it with the actual condition. Closed Loop control systems do this by generating an error signal which is the difference between the output and the reference input. A “closed-loop system” is a fully automatic control system in which its control action being dependent on the output in some way.

Key Differences Between Open Loop and Closed Loop control

Open Loop Control

  • Controller has some knowledge of the output condition.
  • The desired condition is not present in the control loop – hence the Open Loop.
  • Any corrective action requires an operator input to change the behavior of the system to achieve a desired output condition
  • No comparison between actual output condition and the desired output conditions.
  • Close Loop control has no regulation or control action over the output condition ! Each input condition determine a fixed operating condition for the controller.
  • Changes or disturbances in external conditions does not result in a direct output change unless the controller and manually altered.

Closed Loop Control

  • Controller has some knowledge of the output condition.
  • The desired condition is compared to the actual condition to create an error signal. This signal is the difference between the input signal (the desired dryness) and the output signal (the current dryness).
  • Closed loop means feedback not just for recording the output, but for comparing with the desired state to take corrective action.
  • Output condition errors are adjust by changes in the controller function by measure difference between output and desired condition.
  • Output conditions are stable in the presence of an unstable system.
  • Reliable and repeatable output performance results from corrective actions taken from the error signal.

Using Closed Loop Control for a Project

  • The Setting – we work in an enterprise IT environment, a product development company, or on a mission critical software project.
  • The Protagonist – Those providing the money need information to make decisions
  • The Imbalance – it’s not clear how to make decisions in the absence of information about, the cost, schedule, and technical outcomes from those decisions.
  • Restoring the Balance – when a decision is made, it needs to based on the principles of microeconomics, at least in a governance based organization. The decision
  • Recommended Solution – start with a baseline estimate of the cost, schedule, and technical performance. Execute work and measure the productivity of that work.

Using these measures to calculate the variance between planned and actual. Take management action to adjust the productivity, the end date, the budget – using all variables produce a new Estimate To Complete to manage toward.

This is a closed loop control system

The Microeconomics of Decision in Closed Loop Control

Microeconomics is the study of how people make decisions in resource-limited situation on a person scale. It deals with decision that individual and organizations make on such issues as how much insurance to buy, which word processor to buy, what prices to change for pro ducts and services, which path to take in a project. Throughput the project lifecycle, these decision making opportunities. Each decision impacts the future behavior of the project and is informed by past performance and the probabilistic and statistical processes of the underlying project activities. To make an informed decision about the project, estimates are made using this information.

Microeconomics applied to projects is a well understood and broadly applied discipline in cost account and business strategy and execution. Decision making based on alternatives, their assessed value and forecast cost. Both these values are probabilistic. Microeconomics is the basis of Real Options and other statistical decision making. Without this paradigm decision are made not knowing the future impact of those decisions, their cost, schedule, or technical impacts. This is counter to good business practices in any domain.

Let's Look At An Open Loop Control System

Screen Shot 2016-01-23 at 3.17.28 PMThis is all fine and dandy. But where are we going? What's the probability we will arrive at our desired destination if we knew what that destination was? Do we have what we need to reach that desired destination if we knew what it was? In Open Loop Control these questions have no answers.

Let's Look at a Closed Loop Control System

Screen Shot 2016-01-23 at 3.18.42 PM

We want to manage our projects with Closed Loop Control Systems

Related articles Who's Budget is it Anyway? Your Project Needs a Budget and Other Things The Actual Science in Management Science Control Systems - Their Misuse and Abuse Building a Credible Performance Measurement Baseline Open Loop Thinking v. Close Loop Thinking
Categories: Project Management

Forecasting Cost and Schedule Performance in the Presence of Uncertainty

Fri, 01/22/2016 - 17:28

Estimating in the presence of uncertainty is a critical success factor for all project work. Uncertainty prevails on all projects, no matter the domain, development process, or governance method.

Uncertainty from underlying statistical variances. Uncertainty from probabilistic events.

Here's an approach to estimating the cost and schedule impacts from those uncertainties.

Forecasting cost and schedule performance from Glen Alleman

 

Related articles Intellectual Honesty of Managing in the Presence of Uncertainty Essential Reading List for Managing Other People's Money
Categories: Project Management

Risk Management is How Adults Manage Projects

Wed, 01/20/2016 - 19:44

Risk Management is How Adults Manage Projects - Tim Lister

Tim's quote offends some people. Here's a collection of his presentations. But this not really the point of this blog. I'm working two programs where Agile (Scrum and SAFe) is integrated into the Earned Value Management System, complaint with EIA-748-C and the guidelines for deploying, using, and reporting progress to plan with that system. This integration is directed by FAR 34.2 and DFARS 234.2 on Software Intensive System of Systems programs.

These programs are similar to Enterprise IT programs, they have mission critical outcomes, they are expensive, they have high risk, they are not simple structure - by definition, and they have deadlines and budget goals set of the enterprise for maintenance of corporate performance.

Outside of the programs we work, we encounter much confusion around risk management, the source of risk, and the separation of the effective and non-effective process of managing risk in the presence of uncertainty. Let's start with a framework for making decisions in the presence of uncertainty. This briefing has been shown before here, many times. But it can't be shown too many times, because there is much misinformation about how to manage in the presence of uncertainty. This briefing is part of a much large set of charts developed over several years for an Office of Secretary of Defense for Acquisition, Technology and Logistics. These are the people that buy things for the warfighter and those who support them.

It may not appear to be applicable in all domains, but I'd strongly suggest it is. Because uncertainty is present on all projects. And the risk this uncertainty creates is present on all projects. Uncertainty and the resulting risk cannot be avoided it can only be managed.

The Point

When we hear Agile is Risk Management it's not true. Agile Software Development in the form of Scrum, XP, DSDM, Crystal, and now even Agile Prince2 is just that - a Software Development Method using the principles of agile.

12 Agile Principles

In some domains by the way a few of those principles are violations of governance of other people's money. Many business people have day jobs and aren't going to be available on demand to work with the developers.  standards - DODAF, ToGAF, 1553 Bus, ISO 12207 etc. define architectural processes.

But that aside for now, Agile provides information for risk management through frequent feedback and adaptability. But Agile is NOT risk management for a  simple reason ...  

Agile does not model the uncertainties that underly all project work.  

Agile has no notion of margin. Agile has an informal notion of risk reduction of Reducible Risks (Epistemic uncertainties if you read the briefing). But those irreducible uncertainties (Aleatory) are not addressed by Agile. Research shows the irreducible uncertainties are the killer problems on all project work. These come from the natural variances of humans, processes, and machines.

Screen Shot 2016-01-20 at 8.08.24 AM

Agile in the form of methods has no process model for addressing the reducible and irreducible uncertainties other than to provide data on performance to date to make decisions about mitigations, margin, and management reserve needed to MANAGE Risk in the presence of uncertainty. 

And of course the final tag line

To Manage Risk in the presence of uncertainty we must Estimate not only the probability of occurrence of an Event based risk, but also Estimate the statistical processes of naturally occurring variances and then estimate the impact of those uncertainties creating risk, Estimate the cost and schedule to mitigate those risk, and finally Estimate the residual uncertainty after mitigation.

Yes, Risk Management is How Adults Manage Projects and of course Estimating is how Adults Manage Projects

 

Related articles Agile Software Development in the DOD Risk Management is How Adults Manage Projects What Do We Mean When We Say "Agile Community?" IT Risk Management
Categories: Project Management

Quote of the Day

Tue, 01/19/2016 - 13:25

Great equations change the way we perceive the world. They reorchestrate the world - transforming and reintegrating our perception by redefining what belongs together with what. Light and waves. Energy and mass. probability and position. And they do so in a way that often seems unexpected and even strange.

- Robert P. Crease, The Greatest Equations Ever, Physics Web 2004, in The Mathematics Devotional: Celebrating the Wisdom and Beauty of Mathematics, Clifford A. Pickover

Categories: Project Management

Capabilities Based Planning

Mon, 01/18/2016 - 19:21

I'm working two programs where Earned Value Management, through FAR 34.2 and DFARS 234.2 are applicable. These programs are also Software Intensive Systems applying Agile development processes. Capabilities Based Planning is defined as ...

A method involving the functional analysis of operational requirements. Capabilities are identified based on the tasks required
 Once the required capability inventory is defined, the most cost effective and efficient options to satisfy the requirements are sought. Capabilities Based Planning is planning, under uncertainty, to provide capabilities suitable for a wide range of modern-day challenges and circumstances while working within an economic framework that necessitates choice.

In tradition Agile (I know agilest will be wincing) the development of requirements is emergent. On Sofware Intensive System of Systems in the domain where FAR / DFARS are applicable, we have deadlines and mandatory Capabilities for the outcomes of the work effort. The system must perform in specific ways on specific dates for specific costs.

This specificity of capabilities, cost, and delivery dates is no different than on Enterprise IT projects

When applying Agile Development has to address how do we bound the program in a contract vehicle? The Agile Manifesto of Customer Collaboration Over Contract Negotiation is fine except when dealing with a sovereign. So here's how its done.

Capabilities Based Planning

The needed Capabilities are on contract. The technical and operational requirements needed to provide those capabilities can be emergent and are suitable to agile development methods.

Here's some posts from the past about Capabilities Based Planning

And of course ...

To make decisions about the analysis of alternatives using Capabilities Based Planning, estimates must be made of the outcomes for each choice in the list of alternatives. Without estimates, there can be no Analysis of Alternatives to determine which capabilities are best suited to meet the mission need or fulfill the business case. There can be no credible decisions in the presence of uncertainty without estimates.

Related articles How Think Like a Rocket Scientist - Irreducible Complexity What Do We Mean When We Say "Agile Community?" Can Enterprise Agile Be Bottom Up? Seven Principles of Agile Software Development in the US DOD Two Books in the Spectrum of Software Development There is No Such Thing as Free Empirical Data Used to Estimate Future Performance Agile Software Development in the DOD Thinking, Talking, Doing on the Road to Improvement
Categories: Project Management

Quote of the Day

Tue, 01/12/2016 - 16:52

There is no problem so complicated that you can't make it worse - a common phrase in the astronuaght business

Categories: Project Management

Quote of the Day

Mon, 01/11/2016 - 00:47

The impression that "our problems are different," is a common disease that afflicts management to work over. They are different, to be sure, but the principles that will help improve the quality of product and service are universal in nature - W. Edwards Deming

So when we hear some new and controversial conjecture is the solution to the smell of dysfunction, ask for tangible, testable, verifiable evidence that this new approach is not a solution looking for a problem to solve. 

Categories: Project Management