With the plethora of opinions on estimating - some informed, many uninformed - here's my list of books and papers that inform our software estimating activities for Software Intensive Systems. These books range for hard core engineering to populist texts
- Estimating Software-Intensive Systems: Projects, Products, and Processes, Richard D. Stutzke, Addison Wesley. For nontrival projects, this is the starting point. Stutzke provides in depth assessment of the processes and techniques for estimating complex System of Systems based on software.
- Software Estimation: Demystifying the Black Art, Steve McConnell, Microsoft Press. McConnell, provides an in depth look at the problems of estimating software projects and solutions for each problem. The notion that
is not actually true after you have read the book. So please read the book and see how McConnell provides step-by-step actions for producing credible estimates.
- Software Cost Estimation with COCOMO II, Barry Boehm, et al, Prentice Hall - this is the basis of most parametric estimating tools today. CCOMO II can be tuned for a wide variety of domains. Download the tool, try it out, see what it can do for you.
- Software Engineering Economics, Barry Boehm, Prentice Hall - writing software for money, especially others peoples money is a Microeconomics problem. These class of problems consider descions about the impact of future outcomes as opportunity cost decisions. Since these decision have future impacts, estimates are needed for both the cost and impact. Writing software for money requires making estimates.
- The Discipline of Software Engineering, Watts Humphrey, Addison Wesley - this was one of the orginal texts on how to build software products and the processes needed to assure success. Agile came along later, but many of the principles found in Humphrey's book are still applicable. The reason is agile is mostly about coding and the development of incremental results. Above that level discovering requirements derived from capabilities is still a core process.
- Forecasting and Simulating Software Development Projects, Troy Magennis - this book is the agile version of several of the books above. Monte Carlo Simulation is used and development of the needed capabilities follows the approach found in many enterprise domains.
- Software Sizing and Estimating, Charles Symons, John Wiley - this is a handbook for estimating. Function Points are not a broadly used as they once were, but again the principles are still applicable.
- Economics of Iterative Software Development: Steering Toward Better Business Results, Walker Royce, Kurt Bittner, and Mike Perrow, Addison Wesley - software development is Microeconomics. This is an immutable principle. This book explains how to apply this principle in an iterative domain.
- Facts and Fallacies of Software Engineering, Robert Glass, Addision Wesley - a must read to counter the fallacy that decisons can be made in the absence of estimating the outcomes of those decisions.
- The Incremental Commitment Spiral Model: Principles and Practices for Success Systems and Software, Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong, and Richard Turner, Addison Wesley - the current Software Intensive Systems world is moving toward this approach for government systems.
Estimating software development starts with understanding what the software system is supposed to be doing and how we're able to measure that. This process is based on defining the needed capabilities, the measures of Effectiveness, Measures of Performance, Key Performance Parameters, and Technical Performance Measures all needed for the ultimate success of the project. Along with a Plan showing the increasing maturity of the delivered capabilities. If we don't these in some form, it's going to be a disappoiintment for those payinig for our efforts when they get to the end and the outcomes are what they were expecting.
Capabilities are not Requirements. Requirements implement Capabilities. Capabilities are pretty much fixed while the Requirements evolve. Capabilities Based Planning is the basis of project management in many Software Intensive Systems.
- System Management: Planning, Enterprise Identity, and Deployment, Jeffrey O. Grady, CRC Press
- System Requirements Analysis, Jeffrey O. Grady, Academic Press
- Systems Engineering: Coping with Complexity, Richard Stevens Peter Brook, Ken Jackson, and Stuart Arnold, Prentice Hall
- The Requirements Engineering Handbook, Ralph R. Young, Artech House
- Requirements Engineering: A Good Practice Guide, Ian Sommerville, and Pete Sawyer, John Wiley & Sons
- The Art of Systems Architecting, 2nd Edition, Mark W. Maier and Eberhardt Rechtin, CRC Press.
With the project's capabilities defined to a level needed to start the project - failing to do this results in a Death March at worse, and spending the customer's money to discover what should have been discovered before starting. With the capabilities, the project needs to be managed in a way that will increase the probability of success.
- F.I.R.E.: How Fast, Inexpensive, Restrained, and Elegant Method Ignite Innovation, Dan Ward, Harper Business
- Agile Project Management, Jim Highsmith, Addison Wesley.
- Agile Estimating and Planning, Mike Cohn, Prentice Hall
- Reinventing Project Management, Aaron Shenhar and Dov Dvir, Harvard Business School Press.
- The Management of Projects, Peter W. G. Morris, Thomas Telford.
- Project Management and Methods, Sven Antvik and Håkan Sjöholm, Studentlitteratur AB
- The Handbook of Program Management: How to Facilitate Project Success with Optimal Program Management, Dr. James T. Brown, McGraw Hill.
- Technical Management, Jack V. Michaels, Prentice Hall.
- Project Management the Agile Way: Making It Work in the Enterprise, John C. Goodpasture, JR Ross
- Herding Chickens: Innovative Techniques for Project Management, Dan Bradbary and David Garrett, Harbor Light Press.
- Maximizing Project Value: A Project Manager's Guide, John C. Goodpasture, Management Concepts
- Performance-Based Project Management, Glen B. Alleman, American Management Association
So when you hear of some new approach to project management, ask if there is any connection to a domain and a context in that domain. Because there any many ideas about how to improve the probability of project success. But without a domain and context it'll be hard to assess if they are applicable to your specific situation. Here's one way to think about this domain dependency. From solo projects to national assets, methods, processes, tools are different as is the value at risk.