Brooks Law Is Applicable To Many Collaborative People Activities
Brooks Law is that there is an incremental person, when added to a software project, that makes it require more, not less time. And adding people to a late software project makes it later.
I have been spouting Brooks Law for over 20 years for software projects. You know the drill. An important project is late. So the first inclination is to add more people, or put in a red team, or something to speed it up. Unfortunately when Brooks Law comes into play, those additional people make the project fall further behind. What happens is that for each additional person, there is some energy lost as they need to communicate with others. At some point the project has all the people it can handle. And adding people makes the project later. Even if the project could absorb more people, the reduction in productivity as the in-place team has to communicate with the additional staff on the late project causes the late project to get later.
Using this information we can determine where Brooks Law might kick in at any point in the project and can compute the minimum time – the point at which people have been added at the maximum rate that is still productive, and hence a minimum staffing time and numbers of staff. We can also determine the inefficiencies of overstaffing and the schedule penalty / cost improvement from using an optimal effort schedule as well. This is one of the core models within SEER for Software (SEER-SEM).
Although I have generally discussed this phenomenon in software projects, the same applies to hardware, IT or other engineering projects. And even on assembly projects.
I recall working at a cannery one evening. This was a facility that canned food for the needy. We had a great turnout, probably over a hundred people anxious to help. As the peaches came down the conveyor belt, the main job was to cut off any bad parts. Each person, wanting to help, picked up all the peaches they could and cut something off. I am sure the net pounds of peaches canned was well below what it would have been with the right number of people on the line.
And hardware development projects have nearly the same issues as software projects. Add too many people too early and there will be wasted energy. The project can take longer.
The opposite is also true, to a point. Assuming a project is planned with a longer schedule and fewer people from the start: Fewer people on a project can extend the schedule but fewer communication paths cause the total effort to be less.
The basic issue of Brooks Law can be expressed in the equation:
n(n − 1) / 2
This equation computes how many different communication paths exist between team members. Thus the larger the team, the more time people spend communicating rather than making progress. So adding people to a project that is already late increases those communication paths and takes more of the time of those who should be making progress.
Figure 2 illustrates that there is a minimum time for any software project to be completed (it can be shipped sooner but to be really ready to ship this minimum time comes into play.) Additionally, some cost maybe saved by a planned longer schedule (but not many projects in the US are willing to wait longer… In general, Europe is much more appreciative of the lower cost opportunities.) up to the optimal effort point where the cost begins to rise again.
PS: Use caution when some claim Brooks law is no longer valid. Proper application of Brooks law should look at individual teams working on individual programs, not an entire large system all at once.
References:
Excellent Knol on Brooks law.
“The Mythical Man Month” is a classic in software engineering, written by Frederick Brooks and describes Brooks Law in detail.
Wikipedia, The Mythical Man Month
Software Sizing, Estimation and Risk Management: when Performance Is Measured Performance Improves“ by D. Galorath and M. Evans.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Estimating and ITIL
As we look at ITIL it is somewhat difficult to see the estimation and planning components. Looking on the web I found the ITSKEPTIC had some strong comments / observations as follow:
When we hear it pronounced that it acceptable for ITIL to be full of holes because one shouldn’t rely on ITIL – one should mix and match from multiple frameworks: ITIL, COBIT, CMMI-SVC, MOF, USMBOK, FITS, Six Sigma, ISO20000, PRINCE2, MoR, ISO9000, ISO27001, ValIT, ASL, BiSL, ISO38500… Personally I think it is the greatest failure of our profession that this is the case, but it is what it is … for now. It is absurd to expect IT operations people to have the knowledge and skills to do that – they must rely on external consulting experts (who are the ones who proclaim the “mix and match” principle most loudly). The number of ITIL Experts who have a strong knowledge across enough of these frameworks in order to make informed best practice decisions on Mix and Match is how many?
Estimating and planning is a best practice whether you are deploying ITIL or any other process framework. Viable estimates yield achievable plans yield successful systems.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Agile Development Mature Scrum
Thanks to Tom Gilb for the article on a CMMI level 5 company that implemented Agile . I think the most interesting experiences documented in the paper are
- ”Project Planning in CMMI is a disciplined and comprehensive sprint zero”
- “Two levels of planning and tracking: project as a whole and each sprint”
It is so good to see organizations recognize the project planning is a key part of Agile methods, not just “go forward and hack.”
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
SEER Users Seminar In EL Segundo, October 8, 2009
I just had the opportunity to review the agenda for this one day, no-cost seminar. I was very impressed. Be sure to sign-up today if you can make it.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Improving Earned Value With Statistics
I attended a very interesting session presented by Eric Druker and Dan Demangos of Booz Allen Hamilton and Richard Coleman of Northrop Grumman Information Systems, at the Department of the Navy Cost Analysis Symposium (DONCAS) last week covering improving Earned Value (EVM) analysis with statistics. The speakers covered many of the common points regarding EVM weaknesses and showed some work they had done in helping solve some of these issues.
I found it interesting that SEER-SEM’s Parametric Progress analysis solves the same problems by looking at EVM type data and parametrics in concert.
The Problem Statement from the briefing included:
- Currently, the traditional Earned Value Management calculations suffer from several shortcomings that lessen their viability as a cost estimating tool
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Optimism: The Enemy Of Successful Acquisitions
I attended an excellent talk by Mr. Rich Hartley, Deputy Assistant Secretary of the Air Force (Cost and Economics) last week. There were many interesting and informative points. And the one that struck me the most were his observations regarding optimism. He referred to a Harvard Business Review article ”Delusions of Success How Optimism Undermines Executives’ Decisions“ He summarized the findings related to cost estimating and analysis as follow:
When planning major initiatives
- Routinely exaggerate benefits and discount costs when projecting risky project
- Sets up project for failure; psychologists “planning fallacy”–spin success scenarios and overlook potential for mistakes
Optimism traced to cognitive biases and organizational pressures
- People highly optimistic most of the time –exaggerate talents and degree of control; attribute negative consequences to external factors
- Competition ($, time) for new projects –incentive to accentuate the positive
- Anchoring magnifies optimism –initial plan accentuates positive, skews subsequent analysis
- Most pronounced for initiatives companies have never attempted before
Temper w/ “outside view”
- Supplements traditional forecasting w/ statistical analysis of analogous efforts –reality check on initiative inside view
- Don’t remove optimism, but temper effects –balance between optimism and realism -goals (motivate) and forecasts (decide whether to make commitment in the first place)
The abstract, from the HBR website follows:
The evidence is disturbingly clear: Most major business initiatives–mergers and acquisitions, capital investments, market entries–fail to pay off. Economists would argue that the low success rate reflects a rational assessment of risk, with the returns from a few successes outweighing the losses of many failures. But two distinguished scholars of decision making, Dan Lovallo of the University of New South Wales and Nobel laureate Daniel Kahneman of Princeton University, provide a very different explanation. They show that a combination of cognitive biases (including anchoring and competitor neglect) and organizational pressures lead managers to make overly optimistic forecasts in analyzing proposals for major investments. By exaggerating the likely benefits of a project and ignoring the potential pitfalls, they lead their organizations into initiatives that are doomed to fall well short of expectations. The biases and pressures cannot be escaped, the authors argue, but they can be tempered by applying a very different method of forecasting–one that takes a much more objective “outside view” of an initiative’s likely outcome. This outside view, also known as reference-class forecasting, completely ignores the details of the project at hand; instead, it encourages managers to examine the experiences of a class of similar projects, to lay out a rough distribution of outcomes for this reference class, and then to position the current project in that distribution.
I recommend spending the $6.50 and purchasing the article if you haven’t seen it.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Top 10 Reasons For Poor Cost Performance in Aerospace & Defense
From Janes ” Intelligence and Insight You Can Trust.. A top 10 list of reasons for poor cost performance:
- Unsound assumptions
- Poor definition of requirements –cost baseline w/o credibility
- Series of program plans de’jour
- Assuming benefits of never before demonstrated initiatives
- Assuming Moore’s Law saves $ vice greater functionality for same $
- Aggressive program schedules
- High percentage of development COTS/heritage/re-use software
- Test plans that do not replicate flight-like conditions
- Soft funding
- Inappropriate learning curve assumptions
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
SEER Supporting Open Services For Lifecycle Collaboration Community
Galorath’s Lee Fischman provided this insight on collaboration.
From an introduction provided at http://open-services.net/, “the Open Services for Lifecycle Collaboration (also known as OSLC or Open Services) is a community effort to help software delivery teams by making it easier to use lifecycle tools in combination. The OSLC community is creating open, public descriptions of resources and interfaces for sharing the things that software delivery teams rely on, like change requests, test cases, defects, requirements and user stories. By agreeing on common specifications for lifecycle resources and the services to access them, we can eliminate traditional barriers between tools and open the door to new forms of collaboration. OSLC can bring value to software delivery teams and tool providers alike, from the most Agile to the most ceremonial of projects, and for commercially-licensed, open source, and internally developed tools.” Galorath is working with IBM and other partners to develop protocols for the transfer of information to and from its estimating tools. There are many uses for estimating information passed in a standardized format that can be widely read. For example, the user of a portfolio planning system will be able to pull project estimates from SEER directly into the portfolio analysis. OSLC is one story in Galorath’s longstanding commitment to an open architecture, from configuring SEER models through their easy-to-use API, to permitting nearly all SEER estimating information to be exported. OSLC will mark Galorath’s entry into a protocol supported and maintained by industry.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Computing the Business Value of IT
While I am a strong proponent of examining the business value of IT systems in terms of return on investment, net present value, internal rate of return and other quantified measures. There are some additional considerations that should be used with prudence:
- Intangible Benefits: For example improved customer satisfaction, better image.
- Additional Future Benefits From Groundwork Laid By This Project: For example: deploying a new CRM system that lays the groundwork for a human resources system within the same structure.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
New Release of SEER for Manufacturing Includes Refined Machining Model
What an interesting journey SEER for Manufacturing (SEER-MFG, formerly known as SEER-DFM) has had in development. Continued adding of additional manufacturing process has led the way. And the latest release includes a completely redone machining model as well.
As major organizations continue to apply SEER-MFG to reducing costs there has been an increasing number of users who wanted the detail in the estimate to be sufficient for machine scheduling. The Galorath staff, led by Dr. Chris Rush, Keith Garland and Joe Falque, along with the excellent software developers, accomplished this and much more including updates to composites modeling and other often requested processes. Congratulations team.
And congratulations to the customers who are using SEER-MFG to continually drive down costs, both in manufacture and in parts costing and decision process.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Project Prediction Infographic
