Projects produce products, services, solutions. Projects deliver capabilities that fulfill Missions and Vision, Projects are a vehicle to accomplish and outcome. Projects collect nonrecurring costs in exchange for that produced value. Every project should have a goal, an objective, and outcome. Projects in various domains have different practices and processes. But each of those should be anchored on a set of Immutable Principles.
Here's a set of Principles, Processes, and Practices that have served us well for a decade or so.
So let's look at these in more details
The Five Principles of Project Success
- What Does Done Lool Like? It's popular in the agile work to claim SW is never Done. That may be a nice idea, but from the balance sheet Point of View, Done means we can record the capital expense or we can record the Capital Income from the software. FASB 86 speaks to this as do other accounting practices. Now we may have continuing versions of the software, but at some point done means we are shipping a version to those who paid for that version (even if they are renting the software) and we have recorded that as an event. In the Change Control Paradigm, that version has a version number, it has a branch in the version tree, and we are not changing that code base without updating the version number. That version is Done. Projects produce outcomes. Done needs measures. These start with Measures of Effectiveness and Measures of Performance. These need to be written down before starting, otherwise, you won't recognize then when or if they appear.
- How Do We Get to Done? No matter the approach to delivering outcomes, some sort of Plan is needed. It can be a formal Integrated Master Plan, a Product Roadmap, and checklist, or something in your head. But a Plan is needed. Plans are strategies. Strategies are Hypotheses. Hypotheses need to be tested to confirm they will hold up in practice. So Plans are meant to be tested and Changed when found to be wanting. Anyone suggesting plans and planning is waste has not be held accountable for any non-trivial deliverable. The Plan tells us what to expect at specific points in the project. We Plan to have the first instance of the customer enrollment systems working by the end of the First Quarter, so we can switch over to the new customer tracking system. Or we Plan to have the heat shield integrated with the spacecraft ready for the static testing down at the Cape by the end of the summer. A Plan states intent and a date when that intent will be true.
- Do we have everything we need for the Plan to produce Done? - resources include everything need by the project. People, money, facilities, technology. Anything needed for the success of the project. These resources need a plan. A time phrased plan for their acquisition, deployment, management, and funding.
- What could possibly go Wrong? - risk management is how adults manage projects - Tim Lister. This is the basis of managing projects. All risk comes from uncertainty. Uncertainty comes in two forms - epistemic and aleatory. Epistemic uncertainty is reducible. Work can be applied to reduce the uncertainty. Aleatory uncertainty is irreducible. Only margin can be applied to this uncertainty. Schedule margin, cost margin, technical margin.
- How are we going to measure progress to our Plan other than the passage of time and consumption of Money? - Physcal Percent Complete is the only means of measuring progress to plan. The defined physical percent complete at a pre-defined time and pre-defined value. When that time comes, the measure of physical percent complete is assessed and any variances used to make corrective actions.
So in the - or actually the beginning - the Five Immutable Principles all need to be in place before the probability of project success can be increased
