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!
There are endless reasons for why projects fail. Some are correct, some are bogus, some are down right nonsense. Into this list I'd like at add my opinion, informed by hands on experience on software intensives programs in defense, energy, bio-pharma, commercial products, and enterprise IT.
It starts and ends, with the
Failure to know what¬†DONE looks like in units of measure meaningful to the decision makers
The starting point for the description of¬†DONE is the clear and concise statement of the Needed Capabilities for the resulting project that produce value for the stakeholders. These capabilities are stated in Measures of Effectiveness.
These capabilities state what the results from the project will do for the business or mission when they are available. The planned availability date is part of their capability. Only then come the requirements, then planning for the delivery of the technical and operational components that enable these requirements. Then several more¬†enablers of projects success are needed.
All these activities, outcomes, processes, methods are encapsulated in the paradigm of Systems Engineering. The picture below are the notional elements of Systems Engineering. This picture is from the FAA Systems Engineering Handbook. This handbook is for the National Airspace System (NAS), a software intensive program to upgrade the exiting software, hardware, and processes.¬†Other agencies and business have similar pictures.
What Does All This Mean?
When we hear¬†our customers don't know what they want. Or,¬†our customers don't know the target budget for the work they are asking us to do for them. What they are saying is¬†I don't know what DONE looks like in an tangible way that can be used to measure the performance of the project.
So one of two things has to happen when this is the case...
So when we here that famous - infamous actually - phrase let's explore. Ask a serious question, and demand a serious answer ...
Who's pay for us to explore to discover what we should have already know?¬†
Don't get an answer? Run away from that project, it's going to be a failed project.
Speaking on Techncial Performance Measures and conducting workshop on same topic with Mr. Kranz and Tom Coonce of IDA.
The right question for any suggested improvement, change, or suggesting we¬†stop doing that¬†need to produce an answer to ...
Does this suggestion increase the probability of project success?
This means tracing the suggestion to the outcome of the project being better, faster, cheaper, or some other tangible measure of improvement.¬†
What does project success look like?
The delivery of agreed-upon capability within established resource constriants, e.g. funding, schedule, facilities.
Five factors are used to assess the success
So Now What?
When we hear about something new, anything new, how can we test it that suggestion against business needs, mission needs, governance, or strategy. This starts with establishing the domain in which the suggestion might possibly work. Then proposing the framework in which it has worked or might work. Then a proposed way to assess the possible benefits of performing the sugegsted solution.
Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand".
Mary Doria Russell
It is that difference that is needed to assess when a idea passes the¬†smell test.¬†
These participants play off each other, react to emergent streams of melody, contribute their own special talent to the music and pretty much work in a a self directed manner over the course of the performance.
While I'm not a fan of analogies, this is a useful one for the purpose here. There are certainly domains where the¬†Jazz analogy describes what is going on in the trio in the picture to the left.
But what about other music? Music that is just as creative, just as moving, just as impactful to the listener. Beethoven's Ninth Symphony's Ode to Joy with the poem from¬†Friedrich Schiller¬†1785 work is an example.
Words that have moved nations and populations.¬†Following Beethoven's Ninth was a movie we saw over the weekend that described this result.
In the Ninth, each performer has a score to follow, led by the conductor, but also by the concert master and the ¬†senior players in each section. The vocals are also led by a senior performer.
In the software business there are likely similar domains and projects. Ones that can be improvised and ones that require conductors, a concert master, and players who follow the score.
In both cases - and this is where the analogy falls apart - is the players are highly skilled, experienced in the art, having played the basic themes 1,000 of times over before improvising or following the score.¬†
The jazz performance is not made up as it goes. OK, fusion is, but that crap makes my head hurt. Melodies,¬†rules for cords are practiced for 10,000 hours (Gladwell), relationships between the players have magical connections not available to mere mortals. The Jazz Trio and the¬†Berlin Philharmonic are populated with highly skilled and experienced professionals. We've all heard our children play in the school band and know what that sounds like. All the platitudes in the world about agile axioms are of no worth without the necessary capabilities to actually get the work done properly.
Applying the notion that agile software development is like¬†jazz¬†makes as much sense as saying¬†I can sit in the 3rd chair of the trombone section¬†(my high school band position) and play my contribution to Beethoven's Ninth without a Curtis Institute degree in performance and 10 years experience (my aunt was a professional pianist in the late 1950's from Curtis).¬†
It's not gonna happen - in both analogies - without the prerequisites of professional performance capabilities. Otherwise the result sounds like we're back in High School Music class with Mr. Meach (my teacher).
So how long will it take us to be capable performing to a level needed to not ¬†smell like we're high school kids in the marching band? I don't know let's make an estimate.Related articles Analogies, the Good, the Bad, and the Ugly The "Real" Root Cause of IT Project Failure
There is a continuing discussion in the agile community about delivering¬†value in the order set by the customer. Along with this discussion is the use of the word¬†DONE. A popular phrase is no requirement or piece of software can be considered¬†DONE¬†until it is put to use.¬†
This is a software developers point of view of course. But there is another view of software based products. It starts with the¬†Measures of Effectiveness for the resulting product. These Measures of Effectiveness are:
Operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in an operation environment, under specific conditions.
This measure of¬†DONE is not directly related to code, testing, requirements or anything like that. It is related to how¬†Effective the software is in delivering the capabilities needed to fulfill the mission or business case.¬†
The individual requirements and pieces of code that implement them can be - or should be - traceable to these capabilities. For each Measure of Effectiveness, we then need a Measure of Performance. These measures characterise:
The functional or physical attributes relating to the system's operation, measured or estimated under specific conditions.
These are also not direclty related to producing code, running tests, or other direct software activities.
All the software design, testing, integration, etc. supports the creation of the¬†ability to produce these Measures of Performance and Effectiveness. For the end user, all the development work is behind the scenes. What the customer actually bought was the ability to do something useful. To put a capability of the software system to work accomplishing a business need. Make money with this capability of course.
So What Does All This Mean?
It means that if you start at the bottom - with the software development processes - you're likley not going to see what the real picture is. This picture is that the customer paid for capabilities, measured in units of effectiveness and performance.
When we start with methods, paradigms, even cockamamie ones like not estimating the cost of the work effort needed to produce the capabilities, we loose the connection to why we are here. We are here to produce software that provides a capability. Likely more than one capability.
So when we hear words like -¬†we can manage projects without knowing the cost¬†or¬†we'll let the requirements emerge, or¬†the customer doesn't really know what they want, so we'll get started so they can decide along the way, ask how you are going to recognize¬†DONE, before running out of time and money?¬†
How Do We Discover the Needed Capabilities?
Once we've decided that capabilities are in fact the place to start, how are they gathered. Here's the top level set of activities.
Once we have these, we can start to elicit the technical and operational requirements that will fullfill these capabilities.
These requirements can be emergent, they can evolve, they can be elicited incrementally and iteratively. But what ever way to¬†appear they need to have a home. They need a reason for being here. They need to enable a capability to be available to the user.¬†
Ninety percent of everything is crud -¬†Theodore SturgeonModels ...
When I hear the phrase¬†we're exploring I'm reminded that in fact many who explore without a plan, measures of their progress progress against this plan, a risk management Plan-B for getting home when things go wrong, and without insufficient resources to survive the trip - come home empty handed or many time don't come home at all. Exploring without these items is called¬†wandering around in the wilderness looking for something to eat.¬†
Here's a simple¬†tale about an actual explorer, Ernest Shackleton, who experienced failure and near death on their first expedition¬†to the South Pole (ADM Scott), that informed his attempt the reach the Pole a second time, only to experience failure again. In the first example prepartion was weak, management inconsistent, and lacking an actual strategy, no Plan-B. The second attempt, without Scott, was well planned, well provisioned, well staffed. When trouble started, Plan-B and then Plan-C were put in place and executed.¬†
¬† What's the Point About Managing Projects? So when we hear¬†we're exploring and there is no destination in mind, or named problem to be solved, or even a description of possible root causes of the un-named problem, remember Shackleton's first trip and Scott's mismanagement of that exploration. On the second trip Shackleton had estimated what he would need, what route he would take, what skills his crew needed, what Plan-B would be, and even Plan-C when that didn't work, and most of all he estimated the probability of success to be high enough it was worth the risk to reach the South Pole and return to tell about it. The Polar expedition for Shackleton was a¬†project, planned and executed with credible estimates of every step along the way, including the possibilities hat everything could go wrong and it did. Through is leadership, they lived to tell about it. Related articles Performance-Based Project Management(sm) Released Agile as a Systems Engineering Paradigm 1909 - Ernest Shackleton, leading the Nimrod Expedition to the South Pole, plants the British flag 97 miles (156 km) from the South Pole, the furthest anyone had ever reached at that time. Black Swans and "They Never Saw It Coming" 3 Impediments To Actual Improvement in the Presence of Dysfunction
In the discussions around #NoEstimates, it's finally dawned on me - after walking the book shelf in the office - the conversation is split across a chasm. Governance based organizations and non-governance based organizations.¬†
Same is the case for product development organizaitons. Those producing a software product for sale or providing a service in exchange for money. There are governance based product organizations and non-governance based product organizations.¬†
I can't say how those are differentiated, but there is broad research on the top of governance and business success using IT. The book on the left is a start. In this book there is a study of 300 enterprises around the world, with the following...
Companies with effective IT governance have profits that are 20% higher than other companies¬†pursuing similar strategies. One viable explanation for this differential is that IT governance¬†specifies accountabilities for IT-related business outcomes and helps companies align their IT¬†investments with their business priorities. But IT governance is a mystery to key decision makers¬†at most companies. Our research indicates that, on average, only 38% of senior managers in a¬†company know how IT is governed. Ignorance is not bliss. In our research senior management¬†awareness of IT governance processes proved to be the single best indicator of governance¬†effectiveness with top performing firms having 60, 70 or 80% of senior executives aware of how¬†IT is governed. Taking the time at senior management levels to design, implement, and¬†communicate IT governance processes is worth the trouble‚ÄĒit pays off.
IT Governance is a¬†decision rights and accountability framework for encouraging desirable behaviours in the use of IT. And I'd add the creation of IT, IT products, and IT services. Since IT is a broad domain, let's exclude development effort for things like games, phone apps, plugins. and in general items that have low¬†value at risk. This doesn't mean they don't have high revenue, but the investment value is low. So when they don't produce their desired beneficial outcome, the degree of loss is low as well.
Asessment of IT Governance focuses on four objectives:
In all four, Weill and Ross provide guidance for assessing the capabilities of IT. In all four¬†Cost is considered a critical success factor.
Without knowing the cost of a decision, the choices presented by that decision cannot be assessed. So when we hear #NoEstimates is about making decisions, ask of those decisions are being made in a governance based organization?
Then ask the question¬†who has the decision rights to make those decisions?¬†Who has the need to know the cost of the value produced by the firm in exchange for that cost. The developers, the management of the development team, the business management of the firm, the customers of the firm?
The three dependent variables of all projects are schedule, cost, and technical perfomance of produced capabilities (this is a wrapper word for everything NOT time and cost).¬†The¬†value at risk is a good starting point for¬†deciding¬†to apply governance processes or not. If you fix one of these variables - say¬†budget (which is a place holder for cost until the actuals arrive), then the other two (time and technical) are now free to¬†vary. Estimating their behaviour will be needed to assure the ROI meets the business goals. In the governance paradigm, these three dependent variables are part of the decision making process. Not knowing one of more puts at risk the¬†value produced by the project or work effort. It's this¬†value at risk that is the key to determining why, how, and when to estimate.¬†
What are you willing to loose (risk) if you don't need to know when you'll be done, or what you'll be able to produce on a planned day, or what that will cost, or determine if the ROI (return on investment), ROA (return on asset value), or ROE (return on equity) to some level of confidence to support your decision making - then estimating is a waste of time.
If on the other hand, the firm or customers you work for writing software in exchange for money have an interest in knowing any or all of those answers to support their decision making, you'll likley going to have to estimate, time, cost, produced capabilities to answer their questions.
It's not about you (the consumer of money). To find out who, follow the money, they'll tell you if they need an estimate or not.Related articles Back To The Future Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Danger Will Robinson Some more answers to the estimating questions Capabilties Based Planning, Use Cases, and Agile The Value of Making An Estimate
These 5 questions need credible answers in units of measure meanigful to the decision makers.
What Does All This Mean?
With these top level questions, many approaches are available, not matter what the domain or technology. But in the end if we don't have answers the probability of success will be reduced.
Lot's of myth floating around about requirements elicitation and management. Starting with requirements is not how large, complex, mission critical DOD and NASA programs work. Start with Capabilities. This cna be directly transferred to Enterprise IT.
Here's a map of the planned capabilities for an ERP system. This figure is from Performance-Based Project Management¬ģ where all the deatails of this and other principles, practices, and processes needed for project success can be found.
Here each business systems capability is outlined in the order needed to maximize the business value. In agile parlance, the customer has prioritized the deliverables. But in fact the prioritization is part of the strategic planning needed to assure that the cost investment returns the maximum value to assure the business receive maintains a positive ROI throughout the life of the project
The first step is to identify the needed capabilities. Here's the steps
Only when we have the capabilities defined for each stage of the project can we start on the requirements. All the capabilities need to be identified and sequenced, otherwise we can't be assured to business goals can be met for the planned investment. With the planned capabilities, we can start on the requirements
With requirements in place for each capability, we can then start development. This is done incrementally and iterative using our favorite agile method. Doesn't mater as long an incremental delivery of value of the approach.
Extensive research has shown given that a current project is more than fifteen percent complete, the overrun at completion will not be less than the overrun incurred to date; and the percent overrun at completion will be greater than the percent overrun incurred to date. Assuming no change in scope or reduction in delivered capabilities, this overrun is locked.
Without knowing the original Estimate At Complete (EAC), the funders of the project have no way of making decisions about the project's total cost, its ¬†incremental cost, or how to adjust scope and duration to meet the expected cost incurred in exchange for the expected value produced from this cost. Without this cost information, and related schedule, and techncial performanc information, the notion of¬†decision making¬†is nonsense.¬†
We can't make a decision without knowing the cost and benefits of the resulting decision
The absence of an estimated cost, duration, and delivered capability prevents the business from knowing if they are making the right decision about the investment in the project. So if decision-making is what management does, not knowing this information prevents credible decisions from being made
Not estimating these three data items ‚Äď cost, schedule, and technical performance (delivered capabilities) ‚Äď is simply bad business management. What ever unfavorable outcomes ‚Äď overruns, failed business capabilities, unhappy customers (ACA the most recent example) ‚Äď is well deserved.
The notion that we can make decision in the absence of estimates of their cost and benefit, appears to be unfounded conjecture, with no evidence of its validity.¬†
Another definition of economics, closer to software developemnt is¬†the study of how people make decisions in resource-limited situations. This definition matches the classical use of the term and is the basis of¬†software economics. Since software product development always takes place in the presence of limited resoruces. Time, money, capabilities, even knowledge. And since software development always is the exchange of those resources for the production of value, looking at development from an economics point of view is a good start for any discussion around improving the process.¬†
Two other definitions are needed before continuing.¬†Macroeconomics is the study of how people make decisions in a resource-limited situation on a national or global scale.¬†Microeconomics is the study of how people make decisions in a resource-limited situation on an individual or organization scale.¬†
For software development, microeconomics deals more with the type of decision making needed for successful projects. And since much of the discussion these days is about¬†making decisions on projects, let's see how the¬†microeconomics paradigm may improve the communication.
There have been suggestions that the book above is¬†old school and no longer applicable to the modern world of software development - e.g. Agile. Since the book is actually about engineering economics ¬†not about software development methods, let's see what the book actually says for those who have not read it, heard Dr. Boehm speak, or in my case worked for the same firm where Dr. Boehm lead our process improvement management effort.
This book was a working text, when I attended USC as a Master's student while working at TRW (Boehm's home) for an Engineering Economics course. The book is still in print and available in¬†used form for low prices. So those wishing to comment on the book, without having first read all 765 pages, can now do so at a low cost.
The preface of the book starts with the usual qualifiers, but contains three important objectives
The major objective of the book is to provide a basis for a software engineering course, intended to be taken at the college senior or first year graduate level
So let's look at chapters to get a feel of the concepts of software engineering economics. My comments on the chapter are in italics.
So What's the Point of All This?
When we hear estimating can't be done for software, we actually know better. It is being done in every software domain. Tools, processes, books, papers, conferences, vendors, professional organizations will show you how.
When we hear this, we now know better.
 "Software Engineering Economics," Barry W. Boehm,¬†IEEE Transactions on Software Engineering, Volume SE-10, Number 1, Januarym 1984, pages 4-21.
 This is the crux of the post, the book and the discussion around the conjecture that we can make decisions about how to spend other peoples money with estimating that spend.¬†Related articles Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices
From the¬†anarchy of gaming coders sitting in the basement of the¬†incubator¬†on 28th¬†and Pearl¬†Street¬†here in Boulder to the¬†full verification and validation of ballistic missile defense system software, 7 miles up the road.
When I hear about how software should be written, how teams should be organized, how budgeting, planning, testing, deployment, maintenance, transiston to business, transistion to production, sustainment, and the myriad of other activities around software development¬†should be done - the first question is always -¬†what's the domain you're speaking about.¬†
Then - have you tested these ideas outside our personal experience. And finally have you tested these ideas in another domain to see if they carry over? If you're just¬†exploring ideas, no problem. But that limits the credibility of the idea to being¬†just and idea with no actionable outcome, other than a conversation. Those paying for the software you are writing for money, usually don't like paying for you to explore using their cash - unless that effort is actually in the plan.
There are of course fundamental - immutable actually - principles for any project based endeavor. These are the Five Immutable Principles of all project success, shown over and again in the root cause analysis of failed projects.
All five of these principles need answers if we're going to have any hope of success. No matter how often it is repeated, insisted upon, or how clever the message is trying to avoid these principles, they're not going away. They are immutable. They need to be answered on day one and on every day until the project is over.
So if we are writing software for money - internal money, external money, maybe even our own money - ask these questions and see if our answers are credible.
More in next post about the economics of writing software for money.
I heard this phrase in a conference call yesterday with a DOD client and thought,¬†how clever I'll write a blog about this. Only to find out there is a Forbes article with same name and several other articles as well.¬†
The Forbes article had a case study about¬†doing it right around a business process. It was the perfect framework (repeated here) for applying¬†Performance-Based Project Management¬ģ¬†
In the Forbes article there are five steps:
In the end project success is about knowing what done looks like, knowing how to get there, how to measure progress along the way. And of course knowing impediments to progress and handling them. These concepts are instantiated in two papers from a colleague Pat Barker,¬†What is Your Estimate at Complete and¬†Program Master Scehdule Can Improve Results, on page 20.
In yesterday's post, the notion of Systems Engineering was suggested as one solutuion to project failure. Here's the next step. The Agile notion started with a manifesto that turned into many interpretations and practices. In the standard project management paradigm, there is a set of principles, practices, and processes described in a variety of ways through several organizations. ITIL, PMI, APM, DOD, DOE, and other¬†owners of project management activities.
When we take the Systems Engineering approach, we can put a wrapper around¬†ALL project management, technical development, and deployment processes, that can be use to assess each practice and process to assure it is providing value. Here's a short overview of this paradigm.¬†
Agile project management is systems management from Glen Alleman The frameworks for Systems Engineering starts with several guides
One of the suggestions in #NoEstimates is the¬†slicing of¬†work - either Stories or any word needed to indicate an agile projects¬†chunking of the work - into small pieces. This of course doesn't actually address the issue of producing and¬†Estimate at Completion for the project. An estimate needed by those funding or authorizing the spending of funds to know¬†how much and when.
But¬†slicing is a process of reducing the exposure to uncertainty to a manageable size.¬†¬†It's the next level down's answer to¬†what's the value at risk? Make in small and reduce the¬†value at risk of not showing up on time and on budget.¬†Slicing¬†answers the question, that has been around for¬†some time.
How long are you willing to wait till you find out you are late (or over budget, or it doesn't work as planned)?
The answer to this ¬†- how long - question varies according to the domain,¬†value at risk, and other factors usually associated with risk tolerance. But it is a question that must be answered periodically (month;y for us) Recently this notion of¬†slicing has been put forth as part of the¬†solution to the¬†estimating problem, which of course it's not. Since the size of the work¬†chunks only reducing the uncertainty of the variance. Both the aleatory (irreducible uncertainty) and epistemic (reducible uncertainty) will be less when the¬†exposure to the uncertainty is smaller. Beneficial to the project for sure. But the total¬†all in cost and schedule are related to the¬†slicing size only by the cumulative variance of the parts.
It many be interesting to know, that¬†slicing¬†is part of ANSI-748 Earned Value Management assessment by the Defense Contract Management Agency (DCMA). DCMA is the DOD agency that¬†validates the Earned Value Management System's 32 Guidelines. DCMA performs a 14-point assessment of the Integrated Master Schedule (integrated because it is connected to the cost based) and the Performance Measurement Baseline (PMB) (the time phased planned budget for all the work).
DCMA Check 8 looks for high duration activities. These are know to cause issues with the exposure to¬†programmatic risk for the program. The 44 day number represents 2 working months. The work then passes through one accounting period (monthly submission of the Integrated Program Management Report). At the end of each accounting period an assessment of¬†Percent Complete is used to calculate the Budgeted Cost of Work Performed (BCWP) - the¬†earned value for the tasks, works packages, and control accounts (funding buckets) for the program. 44 days may sound long for an agile software development project, but 44 days is short on a multi-year, many millions and likley billions of dollars of defesnse work.
Since the agile comminity is ¬†fond of saying¬†there is nothing new here, while suggesting their ideas are new and unique, the above¬†clip is from the DCMA guide, long used in our defense program management paradigm.
So it is worth repeating the¬†principle of asking how long you are willing to wait before you find out something. The rule of thumb is to sample the status of the thing you are controlling are a rate twice your needed to control or determine a value. This is called the Nyquist rate from single processing. Signal processing is where I¬†grew up writing software for Fast Fourier Transforms, Finite Impulse Response Filter, Kalman Filters for particle physics data streaming off the particle accelerator. When I didn't have an orginal idea to finish my PhD studies, I switched to writing the same software for radar signals intelligence, and electroninc warfare systems. Same principles work for any¬†control system including a management control system.
Just as an aside in the control systems paradigm, there is discussion about¬†monitoring and decision making from the information gathered from the monitoring. This is an Open Loop control systems. Without a planned value to¬†seek, the¬†SET POINT if you're using the room thermostat analogy,¬†monitoring the value provide no value, since you don't know what you are¬†seeking the system to do. Just¬†monitoring is Open Loop, you've got numbers from the¬†system the room temperature or the number of stories produced, but no target to control against.
To have a closed loop system, you need a¬†SET POINT, a steering target, a goal, a desired outcome. Then the monitoring - sampling - can produce a variance, a difference between goal and actual - by which you cn take action. Raise or lower the temperature, speed up or sloe down the car, speed up or slow down the production of software outputs. Yes you can go too fast, the down stream user can't take the results and by the time they can, the requirements may have changed. This is the¬†Closed Loop Control.¬†
There is a popular myth that the¬†estimating problem in ¬†software development starts with comparing software development to bridge design and development. This lays the groundwork that software development is not the same as any other engineering discipline and estimating can't be done for software projects
That some how the project paradigm is excempt from the Five Immutable Principles of every other project domain. These immutable principles are:
If we are building bridges the answers to these questions are pretty clear. We are ¬†bending metal into money in ways well established from the past. For software project, these questions still have clear and concise answers, although the answers are developed not from blueprints, but from other means.
Economics of writing software for money
If we accept these immutable principles of project success there are few other immutable principles of business and the management of a business that writs software for money. Either internal projects, where funding comes for the company, or external projects where the money comes from a customer.
First let's look at Barry Boehm's seminal work¬†Software Economics. Some have suggested this idea is outdated. They would be wrong, especially since that suggestion - being wrong - is not backed by any experience or reference of managing the balance sheet of¬†for profit software project. Internal projects where the cost and cost perfomance is outside the persons management responsibility doesn't count.¬†
Show me the money (that you have been held accountable for)
And buy accountable I mean, you lose you job when things go bad financially.¬†
Now with the advent of agile software development, Barry's concepts from long ago need to be updated for iterative and incremental development. Barry by the way instituted the Spiral method in the DOD, replacing the Waterfall method, An recently instituted the¬†evolutionary method replacing the spiral method, starting with Section 803 of the National Defense Authorization Act.¬†
Core business processes are still in place, not matter the software development methods. Those processes haven't been overturned by agile or any other process. We still exchange money for value. The rate of that exchange must be a positive ratio
Value / Cost > 1.0
must be positive if we expect to stay in business for long. Monetizing value is many times difficult up front. Monetizing the work effort may appear difficult to some, but in fact it is not as difficult as it appears. There are many tools, processes, books, training, professional organizations that have field proven solutions to estimating and managinf cost in the software development domain.
Back to the Future on Estimating Software Development Cost (and Schedule)
This approach comes from early in my career. A time by Barry Boehm worked at TRW, along with me and 1,000's of other. My boss, took us¬†young guns aside one day and gave us his standard speach on a pay day Friday.
Everyone take out you pay check. Look in the upper left corner. It says Bank of America and TRW and the branch address. That's NOT where the money comes from to pay you. The money comes from the US Air Force (TRDSS was our program). They pay us to deliver the Statement of Work items for the amount of money we said we woudl on the date (more or less) we said we would. Keep doing that - within the allowable variances - and you'll keep getting those check you can take across the street to deposit in your account.
Customer provides money to do the work needed to provide value. In the TDRSS case, provide the¬†internet in space. When the cost of providing the value exceeds the budget for providing the value, we loose money and likely go out of business.
Not knowing when you're headed for trouble on cost, schedule, or techncial performance is simply bad business. So having an estimated performance target to¬†steer against is mandatory for business success. It can't be any cleared than that. Without that¬†steering target your project is¬†open loop¬†management and you'll be in the ditch before you can steer away from the ditch.¬†Related articles Facts and Fallacies of Estimating Software Cost and Schedule
¬†Related articles Probabilistic Programming in Quantitative Finance Statistical Process Control The Basis of All Modern Control Systems Deterministic versus Stochastic Trends in Earned Value Management Data Quote of the Day - Correlation, Causation, and Statistics Models
Once we've identified the problem, we've gone 80% of the way toward fixing it - Capture Manager, in our morning proposal stand up.