Righting Software Summary

“Righting Software: A Method for System and Project Design” by Juval Löwy, is a book on designing software and software projects. Juval advances that when you make software you are also creating the project to build the software system. Project design is critical. It provides managers with viable choices that trade schedule, cost, and risk of the project. Offering these options is what leads to project success. It is our job as engineers to create an environment that managers can make good decisions. If we do not offer these options, we have no one to blame except ourselves. Finally, creating plans enables managers to consider whether the project is worth doing.

Fuzzy Front End and the Core Team

When dreaming up a software project, start with assigning one and only one architect for the project. Juval describes the lack of an accountable architect as the principal risk of any software project. The architect needs to work with others on the core team from the start of the project design. This core team is composed of a project manager, product manager, and architect. These are roles, not distinct people. The core team’s initial mission is to design the project to enable building the software system. The core team achieves this by determining how long and how much each plan will take.

The Fuzzy Front End

Juval Löwy believes that 15% to 25% of the entire duration of a project should occur in the fuzzy front end depending on project constraints. This period occurs when someone has an idea and it ends when the developers start building. The result of the fuzzy front end is the set of plans to offer to management on how to build the software system. The point of these plans is to understand the schedule, cost, and risk of the project.

The Core Team

The project manager’s job is to shield the team from the company. This person tracks and reports the progress to management and other project managers. Along with other duties like negotiating terms and inter-departmental blockers. The project manager may also assign work to developers, schedule meetings, and, in general, keep the project on course. The product manager’s job is to represent the customer. This person handles customer disputes over features, obtaining requirements, defining priorities, and maintains expectations of the project. Along with what is feasible to work when during the project. The architect is the lead across several activities. Design, process, and general technical input. The architect works with the product manager to create a system design. The architect collaborates with the project manager on the project design. The architect accomplishes defining the what-to-do via continuous hands-on mentoring, training, and reviews. The core team exists throughout the project. Their duties change over time. As large projects can saturate an architect’s time, assign junior architects to tasks throughout the project.

The goal of the project design is to offer management options during the software development plan review. Once management signs off on the SDP document, this becomes the life insurance policy for the project. There is no reason to cancel the project as long as the team adheres to the plan.

Project Design

Project design enables an accurate understanding of the schedule, cost, and risk of the project. The project design includes a staffing plan, scope and effort estimations, software creation and integration steps, a list of all activities, cost calculation, viability and validation of the project design, and the setup.

Effort Estimations

Juval recommends a variety of tools to estimate the level of effort of a project. Obtaining these estimates helps validate the project design. You want to validate there is not a big variation between the system project design and the overall project estimation.

Estimation Tools

• Historical projects
• General Project Estimation Tools
• Broadband Estimation
• Activity Estimations

Critical Path Analysis

Juval Posits, “Critical path analysis is the single most important project design technique.” The purpose of the critical path is to calculate the duration of all essential activities to complete the project. Once calculated, you have a good idea of how long the project will take and where to assign staff.

To conduct a critical path analysis, you will need these prerequisites.

• The system architecture
• A list of all project activities (coding and noncoding)
• Activity effort estimation
• Services dependency tree
• Activity dependencies
• Planning assumptions

Staffing Level

Juval recommends, “always assign resources based on float.” Float represents the amount of time you can delay completing activities without delaying the project.

When considering your level of staffing, you will need to consider these variables.

• Planning assumptions
• Critical path
• Floats
• Available resources
• Constraints

To make the best use of your staff, plan to phase-in and phase-out staff throughout the project. This helps avoid the feast-or-famine cycles. Juval observes that good projects have smooth staff distributions. Rapidly adding or removing people can cause erratic effects on a project.

Project Cost & Efficiency

You can calculate project cost with this formula: Cost = Staffing * Time. You can also see this via a staffing distribution chart. Once you know your project cost, you can also determine your project’s efficiency.

Project efficiency is an excellent indicator of project quality and saneness of the project design. A reasonable range is between 15% and 25% efficiency for a properly designed and staffed project. Any higher efficiency is not realistic. Earned value planning can help you visualize the success of your project. Earned value works by assigning value to each activity toward project completion and the schedule of each activity over time. A successful project should look like a shallow S curve.

With all this information collected, you should be able to mitigate concerns related to various risks. These risks are staffing, duration, technology, human factors, and execution risk. You can cope with other parts of design risk by breaking larger projects into smaller projects. As well as modeling and reviewing risk metrics as the project continues. The organizational structure could also be a risk to your project. If that is the case, the architect can include that as part of the project design. A great benefit of a well-designed project is that these projects are low-stress. As the project executes, quality-control activities continue to ensure project success.

Quality-Control Activities & Debriefs

Below is a list of activities Juval recommends to maintain the quality during the execution of the project.

• Training
  • It is more efficient to train developers on new technology than hoping they will learn.
• Writing up Key Standard Operating Procedures
  • If there are processes that must be followed exactly it is worth writing these down.
• Adopting standards
  • Standards reduce variability in project design and coding practices. Differentiation in project design or coding often does not benefit our customers in any form.
• An engaged quality-assurance professional
  • This person focuses on reviewing quality processes in the development of software. They can also help support the investigation and elimination of root causes in defects or proactively prevent issues.
• Collecting and reviewing key project metrics
  • Metrics enable you to observe issues before they become significant problems. Depending on your processes, you can determine which metrics are worth tracking and reporting on as part of the project design.
• Debriefing
  • It is important to debrief on the work-in-progress and the project once finished.

Debriefing

It is important to debrief the project design and the results of the project execution. You can model, document, and share this across your organization. Debriefing will inspire better project design and implementation of projects. It is crucial to debrief every project and make this part of the software development life cycle. When debriefing, you are looking to learn how to improve practices and eliminate defects in your process.

• Estimations and accuracy
  • Compare the project design estimations to the result.
  • What did you miss and what did not matter?
• Design efficacy and accuracy
  • Were the design plans accurate?
  • Did the estimated team throughput match up with the actual?
• Individual and team work
  • What could be improved, as part of the work of individuals and the whole team?
  • Is it possible to improve productivity or team communication?
  • Were the team members aware of their role in the project plan and how best to contribute?
• What to avoid or improve next time
  • Make a prioritized list of all problems throughout the project related to the people, processes, design, or technology.
  • Indicate if you could have found it earlier or avoided the problem entirely.
  • List anything that should have taken place but did not take place.
  • Include near-misses as they are educational as well.
• Recurring issues from previous debriefs
  • Eliminate problems that occur from project to project. You will save time and effort in future projects.
• Commitment to quality
  • How much of the commitment to quality led to project success? If quality was lacking, what were the reasons?

Conclusion

Juval Löwy defines project success as “meeting your commitments.” Short projects are safe. The importance of project design increases as projects grow in size and risk. Maturing architects have to design projects. When events change during project execution, the project manager and architect will reconnect and redesign the project as needed. With a good project design in place, use quality-control activities to ensure project success.

• One and only one architect must be accountable for the design of the system architecture.
• Your software project needs a project design that results in plans for management to review.
• Debrief your projects and learn from them.