When we hear about all the methods of managing projects, the PMI Body of Knowledge, PRINCE2, home grown and commercial solutions - always look at them in the light of these 5 Immutable Principles and the 5 Practices then implement the principles.
When we hear about all the methods of managing projects, the PMI Body of Knowledge, PRINCE2, home grown and commercial solutions - always look at them in the light of these 5 Immutable Principles and the 5 Practices then implement the principles.
In a recent post titled #NoEstimates - Really? there was an interesting comment.
Clearly, the business value of any feature or project can not be known with much certainty in advance of it being implemented. Still, for the purpose of keeping the analysis simple for now, let’s table this issue for a bit.
This is not the case in a governance based organization or a Capabilities Based Planning organization, where the "valuation" of the resulting product, service, or purchased or built product is part of the planning process.
It's a "build to valuation"
Knowing - to some probabilistic level of confidence - what business value or mission fulfillment the project or product will produce is the core of any decision making process. Knowing the cost of the value is about making decisions, analysis of alterntaives, or assessing the trade space.
With the "estimated" value and the "estimated" cost for that value, a decision can be made in what is called "analysis of alternatives" in our software intensive domain.
Only by having both estimates - value and cost of acheiving that value, their most likely numbers and the probabilistic range of those numbers (measured usually in dollars), can we make that "analysis of alternatives," or "trade space" needed to Govern both the business and the project and products that enable the business to meet its goals.
So there are popular myths around the estimating of cost and value discussion, and a few that are just flat out bogus:
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.
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.
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.
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.
The discussion (of sorts) on Twitter around "no estimates" - what ever that actually means, since there is no definitive description other than exploring - brings me back to my core program management, project management, writing software for money, designing algorithms for identifying moving targets in radar systems, and other software engineering experiences.
Let's start with a fundamental pricniple of all product or service development, either internal or external. While leading a couple hands full of project managers at a large Department of Energy environmental cleanup site, where software development was a critical success factor - and by the way we introduced eXtreme Programming into an ANSI validated Earned Value Management System - our external consulting firm gave us some good advice. We were bidding our technology and services at another DOE site, with similar cleanup problems. We were working on strategies, balanced scorecards, systems architectures, and the like.
That's all nice boys and girls, but here's some fundamental advice - our customer has money and we want it. What's it gonna cost and when will you be done providing the capabilities to close this site?
That's it, that's the winning strategy. The customer has a need, we want to providea solution to it. How much will it cost and when will we have it. If we can answer those three questions - cost, schedule, delivered capabilities, with attached unassailable beneficial outcomes - we will win. This is a business strategy. All the Balanced Scorecard presentations, examples of past performance, deep references of success, are all for naught if the customer can't afford our solution. It comes down to this - and this is where I learned this from the Managing Partner of the Big 6 (at that time) consulting firm.
You can't know the value of something until you know its cost
That's a fundamental principle of all business transactions. Value is always exchanged for cost. We do this when we buy a Venti Nonfat Latte at Star Bucks. We do this when we pay the lawn care company to mow and trim weekly. We do this when we buy anything, including software or the services that produce the software.
This is an immutable principle of commerce
So when we hear, there are alternative ways of writing software for money that don't involves estimating the cost of doing that work, think again. How did you get around the immutable principle of commerce? Now notice I used the word estimate in the same post as know. Yes, estimating allows us to know something to some level of confidence.
I'll estimate that my 1 hour drive to work everyday, will be extended to 1 hour 20 minutes when the snow storm arrives tomorrow night.
I know I'd better have margin in my drive schedule, if I want to attend the 8:30 stand up.
I estimate that it will take 3 days to install and verify the database for the system, given the historical data from the last 3 times we did this.
This knowledge can then be used to plan the access to the server room, arrange for all the verification and validation data we'll need to certify the contents are ready for use by the customer.
We estimate to a degree of confidence, things (time, cost, performance) we'll need to know about to do our job.
So How Can We Learn To Estimate?
Here's where we start. We start with what has taken place in the past. We've never done this before you say. I'd suggest, working literally in the rocket science world, there is very little in the commercial software world that hasn't been done by someone, somewhere in the past. You may not know these people, but it's been done. And more importantly it's the people issues that muck up the project most of the time, not the technical, unless of course it actually is rocket science, or stealth fighter science, or bioscience.
So with the second best basis of estimate approach - What is this like? We've done similar things in the past, how is this problem like those solutions? Next comes the 10 questions approach. The Planning Game. Then a parametric approach. Function Points, COCOMO, SEER, Price-S, SLIM, CoStar, and a long list of other basis of estimate tools, some free can guide you. So when you hear software can't be estimated, change the phrase to I don't know how to estimate software projects, but I can sure look into learning how.
Finally the least desirable way to estimate is to ask the expert. This only works if the expert has been calibrated with a reference class, has her optimism bias in check, knows all about anchoring and adjustment, and has a track record for producing credible estimates. If not, you're going to be disappointed in the result.
But our management uses our estimates against us. Our management doesn't understand the notion of probability and statistics. Our management behaves like Dilbert's boss. This has nothing to do with the need to estimate the cost, schedule, and technical performance of the product and service needed by your customer. It has everyone to do with managing up. And if that's not possible, producing a credible estimate with those risks baked in to protect yourself. And if that's not possible start looking for a better manager or even a better job because your company is going to be in the ditch before long.
So when we hear that estimating is the smell of dysfunction - without ever listing one single dyfunction - remember there are lots of dysfunctions in business. This is normal, because humans are involved. But that dysfunction is not caused by the need to estimate. The need to estimate is a core business process. Doing bad estimates, doing estimates for the wrong reasons, doing estimates wrong - that's a dysfunction that is universal.
In the end you need to either nut up or shut up as Woody says. Yes, that Woody. Learn to estimate for all the right reasons, then when there is an opportunity to have an enlightened manager at your current firm or a new firm, you'll be prepared to contribute value to the business process in ways that benefit the top line.
Since that top line, minus the costs to produce the goods or services is the bottom line (in it's simplest form) is what writing software for money is all about. Knowing the middle line - costs of goods sold (COGS) is critical to actually staying in business.
Shim Marom provides thought provoking posts. The one on Estimates and Not Estimates was a perfect straight line requesting a response.
So some other thoughts:
If No Estimates is about making decisions, then No Estimates better come up with the cost of outcomes of having made that decision or that statement is completely bogus. Time to start looking for business value from our work efforts in building software for money. That means know the cost of our efforts to some degree of confidence before and during the project. Knowing afterward is simple and worthless, that horse ran away and know we're saying how much it costs.
Much of the discussion on building products and services is focused on eliciting requirements, developing solutions around these requirements. Ignoring for a moment the silliness of not knowing the cost or duration of this work effort, we still need to address the business side of spending other peoples money in exchange for delivery a known value.
Over the past months I've come to see the world through the eyes of Systems Engineering. I have a MS in Systems Management, but haven't applied it in 25 years.
My current assignment is on a large software intensive system that is a national asset. This is a code word for it has to work as planned or 100's of million of people, sovereigns, and other users will be disappointed at best and possibly be put in harms way at worst.
This systems view means: (Systems Thinking for the Enterprise: New and Energing Perspectives)
So it all comes down to this:
If you don't know what someting costs - in units of money, schedule, manpower, infrastructure, tools, process risk, delay - you're not going to be able to know what it is worth.
That's it, It's that simple. Anyone suggesting their processes or even a HashTag masquerading as a suggested approach to problems, that this solution will increase the Probability of Project Success (POPS) or their suggested solution is focused on providing value to the customer, must address how that suggestion will work in the presence of the reality of building products and services in exchange for someone else's money.
In a conversation on Twitter with Sridhar, there was mention that product development software projects are different than internal IT projects. And that how they are run is much different as well. This may be the case. It's not been the case in my experience in Enterprise IT for those internal projects. My experience in product development (FileNet, Triconex, Kontron) and software intensive program delivery for government, defense, space, and energy clients is that projects are expected to show up on or before the planned date, at or below the planned cost and with the agreed set of minimal capabilities to accomplish the business goals or fulfill the needed mission.
When internal IT projects lose their ability to show up on time, on budget, with the needed capabilities - all within the probabilistically defined bounds of those measures - then they lose their seat at the table. Internal IT becomes a cost. Sometimes a sunk cost. An expense. A necessary expense, but an expense all the same. And when you're only an expense, those making decisions tend to treat you differently. You have no tangible way to show your worth. In business worth is defined by revenue or cost savings. In both cases worth is defined in units of money. When you have only cash outflow you're likely not to be in the conversation about how to run the business.
There are endless books, articles, and academic papers on the topic of getting a seat at the table. Successfully delivering internal IT in support of the business. Keeping your seat the table on that business requires very specific behaviours, starting with three simple questions:
But the bigger question - the killer question is what are we building and why are we building it? Ignoring for the moment the problem of showing up late and over budget dilutes any value produced by the project, some times to ZERO, we must have a notion of what DONE looks like in units of measure meaningful to the decision makers. Those paying the bills for the project.
Below is a briefing of how to answer these governance questions about what and why. With that in hand the how much, when, and working are straight forward.
There are many books on Balanced Scorecard. Some I find best are:
At The End of the Day
If you can't say, with some degree of confidence, how much you plan to spend, over what period of time, to deliver some tangible value to those paying for your work, you're not in the room when those paying for the work ae deciding what they want you to do. You're considered an expense - possibly a valuable expense.
There are three key elements of every project on the planet - Cost, Schedule, and the performance of the product or service produced by the project. Each of these has drivers. The connections between Cost, Schedule, and Technical Performance are not Iron as suggested in the Iron Triangle of a PMI view of the project. Instead the connections are elastic, springy, flexible. But they are connected.
Cost is driven by:
These costs are themselves variable, as a function of the project phase, external forces for labor, materials, and overhead. But the cost variable starts with these.
Schedule is driven by:
Technical Performance is driven by:
So What Does All This Mean?
But for project success we need to have several things in place. The random behavior has to be knowable. It can't be chaos. If it is chaos, the project will fail, because there is no corrective action.
The three elements need to be known to some degree of confidence.
Do know these to some degree of confidence, you don't know what DONE looks. The only measure of progress becomes the passage of time and consumption of money. It's unlikely any customer is going to be willing to pay you - at least for very long - to spend their money, without some understand of Cost, Schedule, and the resulting Technical Outcomes.
The separation of Project Accounting from Financial Accounting is common in many firms. Finanical Acounting is the domain of the CFO or equivalent and the finance and accounting department, where payments of invoices to customers and from suppliers ae processed.
Project Accounting, sometimes called Job Cost Accounting, is usually the domain of the Project Manager. Where budgets are assigned and records of work peformed and cost of that work reported. But actual money doesn't change hands.
In the Financial Accounting domain, all costs and all income are recorded as transactions on the General Ledger. These transctions are rolled out through accounts to produce a Balance Sheet of the cost versus value in some form. Sometimes that value is revenue. Sometimes, it's business value recorded as intangible asset. Managing of the intangible assets of a firm is the primary role of business leaders. Teh tangible assets are usualy managed in the accounting, by the depaertment with the same name.
I'm making this simple, and likely simple minded for the point that is coming. Who owns the overhead costs that are present in every single business? For larger complex projects here's one framework for doing that, but we'll keep it simple for now.
But before going simple here's a quick looks at FASB 86, the guidance for accouting for the development and use of software. But one quick notion that is missed by many in the agile world not working the arcane processes of public accounting ...
The Agile Alliance is working this issue.
So Back To Project Accounting Processes
Projects spend budget. Businesses spend Funds. If you work on a project, rarely does someone on the business side come to you with an envelope full of money - dead presidents - and say go hire some developers to write code for this project. Those authorizing you to hire people, or buy materials, do so with a Purchase Order of some sort (we have PCARDS that skip all the paper work), or some authorization from HR to hire. The employee or contractor then charges to a charge number or Employee Number to capture their expenses (labor or material).
That expense is then wrapped with fringe, overhead, and other indirects and recorded on the books as the Fully Burdened cost to the project.
Someone Has to Pay
No matter where you work in the organization, the all in cost for the project has to be paid. This includes your direct labor. What you get in your pay check, those fringe benefits - health insurance, matching 401(k), AMC movie passes, spot awards. Your firm has to pay. If you're a 1099 supplier, then it's you that has to pay. As a 1099, if you're not billing your customer for all that overhead than those costs are reducing your revenue. Same for a firm.
So if you're not concerned about overhead, don't manage the project knowing the overhead. Not a problem in principle. In practice though someone does, and if they care, you may want to care as well. If not, then you're likley working as labor on the project. That's in NO way a problem. We're all labor in some form to some one. But when it comes to managing projects and managing the business that projects use or produce, these indirect costs can make or break the project and or the business. Knowing about them, managing in their presence is simply the responsible thing to do. You know likey knowing what your project will cost when it's done.
Here's some background that have served me well over time as a Program Planning and Control manager.
There is a post that references a concept I've come to use that puts uncertainty into three classes. This post it not exactly what I said, so let me clarify it is bit.
First some background. I work on an engagement that provides advice to an office inside the Office of Secretary of Defense (OSD). This office, the inside, is responsible for determining the Root Cause of program performance for ACAT1 (Acquisition Category 1) programs.
These are large programs. Larger than $5B. In most domains outside the ACAT1's this numer is ridiculously large. But inside the circle of large defense programs, $5B is really not that much money. Joint Strike in a Congressional Quarterly and the Government Accountability Office indicated a "Total estimated program cost now $400B," nearly twice initial cost. DDG-1000 is $21,214 Million, yes that $21,214,000,000.
No IT or software development project would come within a millionth of that. If you're interested there are reports at Rand and IDA for the current issues. There are certaintly multi-million dollar IT projects. The ACA web site is probably going to be in the range of $85M to several 100 million. The facts are still coming in. So anyone who says they know and doesn't work directly in the program, proably doesn't know and is making up numbers. GAO will get to the real numbers soon we hope.
Principles Rule, Practices Follow, Everything Else is BS
The principles of cost and schedule estimating, assessment of the related technical and programmatic gaps are the same in all domains for every scale. From small to billion. Why? Because it's the same problem no matter the scale.
The soliloquy in the movie makes a good point -handling the truth is actually very difficult for almost everyone outside the domain - in many instances.
We want the simple answer. We want it all to be fine. We really don't want to do the heavy lifting needed to come up with an answer. We want the simple answer. Many times we don't want an answer at all, we want to just do our job and ignore the fuduciary responsibility to tell others what the cost and schedule impacts are, or even to do our job of discovering that DONE looks like before we start spending other peoples money.
So here's the way out of the trap of at least (1) and (2)
But the words used in the original post that referenced my post are not my intent, nor are they part of any process I work in.
Here's a list of other posts on this topic. It's a crtically important topic. One that deserves deatiled analysis. One that we're obligated to know and use when it's not our money we're spending. It's called Governance.
Here's some more discussion on Estimating for fun and profit.
It's that easy and it's that hard. If you don't have a handle on what risks are going to impact your project, those risks will still be there, you just won't know it.
The first step in increasing the probability of project success is to have some notion of what is going to prevent that success. This means asking what can go wrong, rather than what can go right. In order to answer the question what can go wrong we need to know what we are doing. What is the project about? What are we trying to produce? When do we need to produce it? How much money will we need to spend to produce this things call DONE?
Let's start with some obvious risks that we have to handle for any hope of success of the project. These are obvious because they occur on every project, in every domain, using any project management method.
The first question is who pays for people learning from their mistakes? Then the next question - with these mistakes, did the project advance in ways it would not have before we made the mistake?
And did the money we spent learning from our mistake "earn its value?" Or put in another way was there a better use of the money to advance our learning other than building something that we considered a mistake?
There are other questions as well. Why didn't we know this was going to be a mistake before we started? Or could we have known this before we discovered it failed? Or even better, was the failure we just experienced knowable at all?
This knowability question is the key to all project planning processes. If something is not knowable, then we could not have known, so we only discover our mistake after the fact. If it was knowable and we choose not to address it - ignore the potential problem - then we'll overrun our plan for no good reason other than we choose to ignore the knowable facts.
We may have a knowable issue, but can't afford to learn (pay money to learn), but that's different.
These questions and others need to be asked and answered before we can make any assessment if learning from our mistakes is a good idea. The alternative to learning from our mistakes is to do the job right the first time.
This of course is overstating the solution and somewhat silly, but it brings out a critical concept that must be addressed in any credible management process of spending other peoples money...
Who pays for the development team to discover their mistakes, if these mistakes could be avoided?
Once we have the answer to that question, we now have some decisions to make.
This is all fancy words for someone has to pay for us to learn what we don't currently know. And we need to make the cost of this learning visible as soon as possible if we're going to be good stweards of other peoples money.
So What's the Point?
The notion of Hiring smart people is pointless if they aren't allowed to make any mistakes ignores the managerial finance obligation to determine who pays for these mistakes, is the budget for making these mistakes in the baseline authorization, and if not, are we going to overrun our planned cost for the project and dilute the Return on Investment calculation that we sold to the owner of the project?
We seem to forget that writing software for money, means spending other peoples money for the expected amount of money (within the variance bounds) and showing up on or before some expected time (within the varaince bounds), with more or less the expected capabilities.
This is a Prime Directive (to borrow a phrase) for all projects. It's very doubtful the owner of the money says to us hey boys and girls, go out there and experiment around to figure out what will work and what won't work without actually budgeting for that experimenting work.
When there is explicit budget to experiment that's called explicit work for discovering what we dont' know, that is needed before we can proceed. We'd find that budgeted work in our plan for the project. No problem, all part of the normal project management process.
But the notion of Hiring smart people is pointless if they aren't allowed to make any mistakes needs to address Who, What, When, Where, Why, and How this discovery process is going to get paid for FIRST, then we can start failing on purpose to make the follow on work better.
It's not clear how this notion came about, since I haven't talked directly with those making statement like that. I'll have to estimate myself why this might be true.
One reason might be they haven't been exposed to the statistical processes used to make estimates in a variety of domains, not just project management. When we encounter the need for estimates, we need to come in contact with probability and statistics. All processes on projects are statistical in nature. This produces uncertainty and uncertainty results in probabilistic outcomes.
Estimating means searching in this probabilistic "space" for a number that is close enough to answer a question. How many people are in line for movie tickets inside? Should I buy my tickets at the kiosk outside? Or maybe, how long will it take me to drive from my office to the airport parking garage for my flight on Wednesday morning? These are not exact numbers, these ae quick estimates. The answer to the first question can be made with a quick look inside the theater. The second comes from the experience of driving to the airport several times a month over the past 20 years. One is informed by observeation of the current situation, one informed by past experience under a variety of situations.
Let's start with a simple definition of an estimate - it is an approximation of some value for some purpose, even if the data is incomplete, uncertain, or even unstable. Typically the estimate is derived from a statistical source of data - either observed or referenced in some way.
Making Simple Estimates
When we don't have the exact answer of some value, we can make an estimate of that value. The result is a number and a confidence on that value. Say we need an estimate of how long it will take to drive to the airport. It's 52 miles. Some on surface streets, some on open 2 lane roads, some on freeways. Knowing the speed limit for each of these segments can get us an approximate time portal-to-portal. We can improve the estimate, knowing the weather conditions and the traffic flow on the surface streets.
Let's look at five easy steps for making estimates (abstracted from The "Mother of All Guesses" - A User-Friendly Guide to Statistical Estimation, by Francois Melese and David Rose COPYRIGHT ARMED FORCES COMPTROLLER, 1998)
Making Estimates for Project Work
With the steps above we can start to make estimates of our project work.
But first let's kill some myths used to not to make estimates.
We've heard them all and more. There is an endless list of reasons for not doing most anything on a project, but that doesn't remove our obligation to be stewards of other people's money we are spending with expectation (estimate) of some value in return.
Let's start with a core principle of all project work, and possibly a principle of all life's work when we encounter money.
We can't determine what something is worth until we know what it costs.
This is a crass capitalist point of view I know. But we live in a crass capitalist society and them's the rules. Don't like the rules, it might be better to look somewhere else for work other than spending other peoples money without knowing how much it will cost in the end and when we'll be done.
We all know and maybe even experience a Dilbert's paradigm when it comes to projects. But that doesn't make it right. We hear this some times from management. But we also hear it as an excuse for not making estimates from those who should be looking after the cost needed to compute the Return on Investment.
A Few More Myths
Below are some links to other Blogs on this topic, explore, think about our role in managing other peoples money.
When we hear about software development methods, it's critical to understand in what domain they are applicable. Here's an analogy for that question. Without an answer to this question there is no basis for comparing units of measure. What might be a wonderful approach in one domain would be unusable in another - this is the case for all the examples.
A solo or 3 team project with a customer in the same building would never apply DOD 5000.02, FAR 34.2 Earned Value flow downs. Building the flight avionics to fly to ISS would never use #NoEstimates and emergent requirements on a weekly basis for a 200 person development team spread across the United States.
So before any conversation - beyond shared ancedotes and asking audiences to think about it, because I can't tell you what to do - can take palce, we need to establish the domain, the value at risk, and the governance model applied to our work. Then we can talk about shared ideas.
The NPR story about the Affordable Care Act web site is one of those out of your domain stories. (follow picture link to story) that we see in the popular press.
First is the way over generalized descriptions of Waterfall and Agile. Things like Waterfall development favors listing a huge set of requirements for a system up front, letting developers go away for months (if not longer) and expecting a huge software product in the end.
The simple minded description of agile is stated as The agile method does the opposite, favoring work done in phases, delivering "minimum shippable" parts of a software system in weekly or biweekly cycles. This allows for iterating — or adjusting to hiccups discovered in the previous cycle, changing features or quashing bugs quickly and avoiding getting an end product that doesn't look a thing like what your users need.
Let's get some clarity here. The conjecture that agile would have somehow safed the ACA program is just that pure conjecture.
But let's first look at some possible root causes (page 5 of the linked briefing):
So let's look at page 15's corrective actions and their sources:
So What Does All Mean?
The five immutable principles, practices, and processes of project were violated.