--- title: Software Project Survival Guide by Steve McConnell created_date: 2025-01-07 updated_date: 2025-01-07 aliases: tags: - book type: book book_name: Software Project Survival Guide author: Steve McConnell status: not_started --- # Software Project Survival Guide by Steve McConnell - **🏷️Tags** : #01-2025 #book --- ## Summary > [!summary] Summary > 3 Sentences only! > - What are the main ideas? > - If I implemented one idea from this book right now, which one would it be? > - How would I describe the book to someone else? --- ## Ideas and Thoughts > [!info]+ Inspiring Questions > - Did you think about other concepts from other books? > - Do the concepts fit to your past, to your memories? > - Can you relive them and reflect them from a different angle? - We should define exact goals that are measurable: What does the software need to do? What's its accuracy? --- ## Clippings ### Intro - Software projects fail because of - lack of knowledge of software project conduct - lack of resolve --> indecisiveness, procrastination, low confidence, inconsistency - References - Key Practices of the Capability Maturity Model, Version 1.1 by Software Engineering Institute (SEI) - Recommended Approach to Software Development, Revision 3 by NASA Software Engineering Laboratory (SEL) ### The Survival Mindset - The only outcome considered a failure is total collapse - Success: meet cost, schedule and quality goals within engineering tolerances (+- 10% of goal) - **Survival Needs** - Needs that need to be satisfied before anything else can work (humans: food, shelter, water, air) - project not canceled, team not fired, adequate physical working conditions - meeting personal promises for schedule and functionality - Project team must be satisfied that the project can be completed *at all* before it can worry about the schedule or budget - ![[Pasted image 20250107095858.png]] - Individual developers might not prioritise the same needs as the software projects survival needs #### Stakeholders Each group involved in the project must respect the rights of the other parties. And each group's survival needs must be thoroughly satisfied such that they can focus on higher level needs. Usually this is the *Customer* and the *Project Team*: ##### Customer's Bill of Rights 1. To set objectives for the project and have them followed 2. To know how long the software project will take and how much it will cost 3. To decide which features are in and which are out of the software 4. To make reasonable changes to requirements throughout the course of the project and to know the costs of making those changes 5. To know the project's status clearly and confidently 6. To be apprised regularly of risks that could affect cost, schedule, or quality, and to be provided with options for addressing potential problems 7. To have ready access to project deliverables throughout the project ##### Project Team's Bill of Rights 1. To know the project objectives and to clarify priorities. 2. To know in detail what product I'm supposed to build and to clarify the product definition if it is unclear. 3. To have ready access to the customer, manager, marketer, or other person responsible for making decisions about the software's functionality. 4. To work each phase of the project in a technically responsible way, especially to not be forced to start coding too early in the project. 5. To approve effort and schedule estimates for any work that Team will be asked to perform. This includes the right to provide only the kinds of cost and schedule estimates that are theoretically possible at each stage of the project; to take the time needed to create meaningful estimates; and to revise estimates whenever the project's requirements change. 6. To have my project's status reported accurately to customers and upper management. 7. To work in a productive environment free from frequent interruptions and distractions, especially during critical parts of the project. #### Survival Check This tool is a quick check to verify that the essential characteristics for the survival are met. In the book a πŸ‘πŸΌ or a πŸ’£ is used. We will use a box just like below for every chapter. > [!question] Survival Check - Survival Training > - πŸ‘πŸΌ Project team's survival needs are being met > - πŸ‘πŸΌ The customer and the project team agree to respect each other's software project rights > - πŸ’£ The agreement in principle is not followed in practice ### Software Project Survival Test The idea of the survival test is to check the chances of survival of a project in different stages and to act upon the neglected areas if needed. There is a list of questions that will be answered with 0-3 points, 3 being fully qualified. The questions are separated into the following categories - Requirements - Planning - Project Control - Can progress be tracked and viewed by team members? - defect tracking, source control, project management software - Risk Management - up to date list of risks to the project - Personnel - Do we have all technical expertise? - Are there enough team members and are they committed? - Most projects have a score <50. | **Score Range** | **Rating** | **Description** | | --------------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 90+ | Outstanding | A project with this score is virtually guaranteed to succeed in all respects, meeting its schedule, budget, quality, and other targets. In terms of Chapter 1's project needs hierarchy, such a project is fully "self-actualized." | | 80-89 | Excellent | A project at this level is performing much better than average. Such a project has a high probability of delivering its software close to its schedule, budget, and quality targets. | | 60-79 | Good | A score in this range represents a better-than-average level of software development effectiveness. Such a project stands a fighting chance of meeting either its schedule or its budget target, but it probably won't meet both. | | 40-59 | Fair | This score is typical. A project with this score will likely experience high stress and shaky team dynamics, and the software will ultimately be delivered with less functionality than desired at greater cost and with a longer schedule. This kind of project stands to experience the greatest benefit from applying the plan described in this book. | | < 40 | At Risk | A project with this score has significant weaknesses in the major areas of requirements, planning, project control, risk management, and personnel. The primary concern of a project in this category should be whether it will finish at all. | > [!question] Survival Check - Survival Test > - πŸ‘πŸΌ Project scores at least 60 on the Survival Test > - πŸ‘πŸΌ The project scores less than 60, but corrective actions are planned to improve its score. > - πŸ’£ The project team doesn't follow through on the planned corrective actions. ### Survival Concepts > [!Quote] > An investment made in process at the beginning of the project produces large returns later in the project Processes are important because they make the development more productive and resistant in the long term. Example processes are: - formally write down requirements - use a procedure to control additions and changes to the requirements - Do reviews of all requirements, designs and source code - Develop a written *Quality Assurance Plan*, including a *test plan*, *review plan* and a *defect tracking plan*. - Create an *implementation plan* that defines in which order the components are developed. - Automated source code control (e.g. git) - Revise Cost and schedule after each milestone If teams do not invest in process at the beginning of the project, the amount of time spent for process and thrashing (i.e. unproductive time) will increase (see Figure 3-3). ![[Pasted image 20250107114628.png]] On the contrary, teams which establish processes in the beginning (overhead) will spend less and less time on thrashing and processes as the project moves on. ![[Pasted image 20250107114616.png]] > [!Quote] Overhead of a cancelled Project > If you think that attention to process is needless overhead, consider that the overhead of a canceled project is 100 percent. > [!warning] Opposite Views > - Processes limit developer's creativity > - --> Set up an environment where creativity is still possible. > - Developers feel best in environments where they are the most productive. > - Research shows that in regulated environments people feel more productive. #### Upstream and Downstream Upstream contains all early work of a project, such as requirements definition and architecture design. Downstream refers to later parts such as construction and system testing. Defects cost more (50-200 times more), the earlier in the project they are inserted as illustrated in the figure below. ![[Pasted image 20250107120429.png]] Please note that the cost grows exponentially, which multiplies the effect. > [!Quote] > Successful project teams create their own opportunities to correct upstream problems by conducting thorough, careful reviews of requirements and architecture. Remember that just because no code is being written in the beginning that doesn't mean it is delaying the real work, but rather it is laying the groundwork for the project's success. Erring on the side of too much process is marginally more expensive, versus erring on too little process can be way more expensive (50-200x) in the long run. This is because of the *cone of uncertainty*, which illustrates that upstream decisions affect downstream decisions, but not vice-versa. ![[Pasted image 20250107121222.png]] > [!Quote] > Early in the project you can have firm cost and schedule targets or afirmfeature set, but not both. > [!question] Survival Check - Survival Test > - πŸ‘πŸΌ Project leadership understands the critical role of well-defined processes and supports them. > - πŸ‘πŸΌ The project's processes are generally oriented toward detecting as many problems upstream as possible. > - πŸ‘πŸΌ Project leadership recognises that estimates made during the first half of the project are inherently imprecise and will need to be refined as the project progresses. ### Survival Skills Software projects are inherently complex and therefore need to be planned, controlled and made sure that the progress is visible, people are supported to do the project's work. The risks should be tracked and constantly redeveloped. #### Planning - Think about processes in the upstream period of fixing mistakes at 1/200th of the price. - Rule of thumb: each day spent in processes (e.g. technical review) saves 3-10 days later in the project - Software Development Plan - Project Estimates - Revised Estimates - Quality Assurance Plan - Staged Delivery Plan - Requirements Development - Architecture - Detailed Design > [!Important]+ Planning Checkpoint Review > Very early in the project (at about 10%) success or failure is determined. This means it can be used as a checkpoint to do a *go/no go* decision about the project. At this point the team should have produced: > - user interface prototype (and shown it to users) > - detailed requirements > - detailed project plan including cost and schedule estimates. > > **Mandatory Documents needed for the checkpoint**: > - Name of project's key decision maker > - Vision statement > - Business case for the software > - preliminary effort and schedule goals > - preliminary effort and schedule estimates > - top 10 risks list > - User interface Style Guide > - Detailed User interface Prototype > - User Manual / Requirements Specification > - Software Quality Assurance Plan > - Detailed Software Development Plan > > **Agenda for the Checkpoint Review** > - Is the original product concept still viable? > - Will it be possible to develop a product that matches the project's vision statement? > - Is the business case for the software still justified when updated, more accurate cost and schedule estimates are considered? > - Can the major risks to the project be surmounted? > - Have users and developers been able to agree on a detailed User Interface Prototype? > - Is the User Manual / Requirements Specification complete and stable enough to support further development work? > - Is the Software Development Plan complete and adequate to support further development work? > - What is the estimated cost of completing the project > - What is the estimated schedule for completing the project? Benefits of splitting development into these two funding phases: 1. Cancelling one bad project at the stage of 10-20% can fund many other projects 2. More reliable funding for the bulk of the project, because it can be better estimated 3. Forces project manager to do upstream work in the first 10-20% --> setting the project up for success. #### Risk Management You can hope for the best but should prepare for the worst --> risk management. Typical risks: - failure to plan - failure to follow the plan that has been created - failure to revise the plan when project circumstances change Software development is a high-risk activity, which is why it is essential to perform risk managment. > [!Quote] By Tom Gilb > If you don't actively attack the risks on a software project, they will actively attack you. #### Project Control Without project control every project is *out of control*, which is definitely something we do not want. We do not want to control the people, but rather the project itself: - Choose a software lifecycle model (e.g. staged delivery) to provide a framework - requirements change management --> only update what is necessary - Design and coding standards, to have consistency - write detailed plan of project to align developer's work with goals and to minimize conflicts in between developers #### Project Visibility The visibility is the ability to determine a project's true status, which will give answers to questions like: - Is the project on track to achieve goals? - Are we within 10% of budget and schedule or only within 50%? Good visibility does not come automatically, you have to plan for it! Activities that help achieve visibility: - Vision Statement - Hold a planning checkpoint review after 10% of the project - Regularly compare actual performance against planned performance to check if plan is working and adapt if necessary. - Use binary milestones: they are either done or not done - Drive the project to a releasable state periodically to show project's true condition - revise estimates after each phase to improve planning with more information #### Peopleware The development team needs to be on board in order for the project to succeed. Guidelines to consider the human aspect in software development: - Align Developers' Interest with Work Assignments: - Make work *interesting* - Make *possible goals*: developers usually are realistic and are demotivated by goals that are out of reach - Show developers that you sincerely appreciate them - don't use cheerleading campaigns, impossible challenges or monetary rewards - Provide Thinking-oriented office space - the process is one of continuous discovery and invention --> create atmosphere which is supportive. - Space where developers can concentrate - Avoid open work bays - allows deep concentration - install soda machine or hang out zone for when they don't need to concentrate to foster communication and inspirational discussions. #### User Involvement Don't assume you know what the user wants! Marketers want too many features such that the essential features cannot be found anymore, Developers create technical features that user's don't care about. - Ask users what they want, show them what they intend to build and ask how they like it. Then listen carefully until you fully understand the stated and unstated elements of the users' reponses - Identifying who the user is might be difficult - user needs to be open to mock-ups (very crude prototype) - Adopt easy features and changes immediately and implement larger more complicated changes later on. User involvement saves time because it eliminates a large source of requirement changes: features that no-one needs. #### Product Minimalism Focus on simplicity. Simple solutions are always better than complicated ones. - Focus on taking away components of the software to make it simpler, rather than adding elements to make it more complex. #### Focus on Shipping Software A company makes money by *shipping* software *not by developing* it! > [!question] Survival Check - Survival Skills > - πŸ‘πŸΌ Project Team creates a detailed written plan, designed to eliminate potentially costly problems early in the project. > - πŸ‘πŸΌ Project emphasizes the importance of upstream work holding a *Planning checkpoint review* to make a go / nogo decision when the project is about 10 percent complete. > - πŸ‘πŸΌ Project practices active risk management > - πŸ‘πŸΌ project plan emphasizes visibility and control > - πŸ‘πŸΌ project plan involves real users early and throughout the journey > - πŸ‘πŸΌ project is conducted in a productive environment > - πŸ‘πŸΌ project plan calls for a simple-to-complex approach rather than the reverse. ### Successful Project at a Glance - source code tends to grow in a S-shaped curve where most of the code is written in the middle third of the project. - Staged delivery: ship important functionality fist - keep tabs on clearly defined milestones and deliverables #### Intellectual Phases Different phases of a project have different characteristics. They need to overlap somehow, but we don't want them to overlap too much either. ![[Pasted image 20250108151953.png]] #### Project Flow **Staged delivery!** We want to ship staged versions of the software continuously in order to deliver something that works and improve upon it (ideally with more user feedback). Each stage is released after detailed design, coding, debugging and thorough testing. ##### Benefits of Staged Delivery 1. Critical functionality is available earlier: Because it is usually in the first deliverables. 2. Risks are reduced early: at each stage we have the integration of the different parts which means that different parts of the software are continuously brought onto the same page. You also create tangible signs of progress at frequent intervals. 3. Problems become evident early: You get frequent progress reports which show critical problems that can be addressed early. You will also see if the development team struggles, if they miss the deadline for the first deliverables. 4. Status-reporting overhead is reduced: Shipped and working software is a more accurate status report than a paper report. 5. Makes More Options Available: you have releasable software at all times, meaning if you want to release something is is much less work than if you don't 6. Reduces possibility of estimation error: each delivery is a syncronizing event because you can compare the estimates with what is delivered and improve your estimation skills. 7. Balances Flexibility and Efficiency: It avoids a situation like [[analysis paralysis]], because you can ship a small stage efficiently. ##### Cost of Staged Delivery - You need to retest software at every stage - You need to execute merging and other version control tasks - You need to manage different versions - You need to plan the staged deliveries Some of those costs are just exposed earlier in the process and would remain hidden (but still exist) otherwise. #### Project Phases The phases described above slightly overlap, which is inevitable and desirable. ![[Pasted image 20250108155841.png]] ##### Distribution of Effort ![[Pasted image 20250108160138.png]] ![[Pasted image 20250108160308.png]] Note that e.g. requirements development requires 12% of the time, but only 6% of the effort, because it is less tangible and requires deeper contemplation such that it is done at a slower pace. This also means that it doesn't produce a lot of code. ##### Milestones and Deliverables Use lists from book pages 65ff. > [!question] Survival Check - Successful Project at a Glance > - πŸ‘πŸΌ Project uses a staged delivery approach > - πŸ‘πŸΌ Upper management, customer or both track progress by code growth curve > - πŸ‘πŸΌ Upper management, customer or both track progress by keeping tabs on major milestones and deliverables ### Hitting a moving target #### Change Control --- ```query Software Project Survival Guide Steve McConnell -file: "Software Project Survival Guide by Steve McConnell.md" ```