Software Development Model Bashing

Commentary: In my youth, I would purchase several plastic models. Then using some tools and imagination, I would mix the parts to build a model unique to me. For example, I would mix the parts from a model truck, car, and army tank of various scales to create a monster truck. The technique is known in the model building world as "Kit Bashing". 

In the management world, rarely are projects and operations a text book situation using a  single model right out-of-the-box. What we have most often is a tool kit of a tactics, techniques, and practices. As managers, we must pick and choose which ones best apply then adapt them to our projects. The outcome often is hybrid of tactics, techniques, and practices. In a sense, a "tool kit bashing" process. This is the case with software development as no one model encompasses all that is required for each situation. 

The common approach for the software development model is to spiral from a central concept outwards to final release. In this discussion, I am going to take the spiral waterfall model from the general concept and spiral inward  towards a final objective. Each iteration getting tighter and tighter, closer to the final objective.  The idea is to focus on the business objective and not so much the vehicle or means to achieve the objective. Sometimes we loose focus, scope creep, shifting from the business purpose to cool things such as awesome software applications that performs at quality levels beyond the price point targeted. The problem with this is a cost - objective focus and a loss of a business perspective.

Software Development Model Bashing

The spiral water fall model has been co-opted across many disciplines. This model spirals inward towards an objective through iterative cycles in a closed loop feedback system. In general this process begins with identification of a complex objective that is broken into components that are continually refined moving inward closer towards a final objective. There are generally five steps to the model; identification, planning, design, implementation, and analysis. These are often modified by each discipline utilizing the model to better suit their needs.

For example, the Democratic Reform Process model, DRP model, 1. Identifies a reform, 2. Builds a constituency and financial support, 3. Assesses the organizational structure and shortfalls to  determine  what is needed to implement the reform, 4. Mobilizes resources, 5. Analyzes the outcome to adjust the desired reform for the next go around. The DRP model is interesting since a significant portion of the information technologies are the outcome of a democratization of design given open systems and request for comments, RFCs. I want to return to this notion, democratization of design, through out the remaining post.

 

In software development, the spiral waterfall model is a little more complex and is used in conjunction with the System Development Life Cycle, SDLC, model as well as the project management model.  various practices also apply. One version of the software development spiral waterfall model, itself, is broken into four general sectors; objective determination, risk assessments, development and test, then plan for the next iteration. Within these sectors various management models or elements of other models help structure the conduct of the sector.

The Objective Sector:  This is focused on the project chartering and planning processes of the project management model. It is also associated to the identification and constituency building step of the DRP model. During the original chartering process business objectives are established for the project. These are central to the success of the project and essential to avoiding scope creep during the iterative cycles. The objective remains at the center of the model as the iterations spiral towards them. In this sector effects based structures may be created. The practice is used to measure progress towards an objective. When measures of effectiveness hit established triggers, a decision and/or corrective action is made. This practice can be used to monitor progress towards objectives as the model executes. In the DRP model, this sector is where the objective is determined and the sponsors (primary stakeholders and constituents) are sought in order  to build financial support.

The Risk Assessment Sector: This is associative to the risk planning processes of the project management model. It is also part of the DRP model that assesses the organizational structure and shortfalls. In short, risks are identified and placed into the risk register. A risk breakdown structure could aid in the management of risk as well. Contingencies and responses are planned in the case a risk event occurs.  Effects based triggers and measures of effectiveness can be used in a Statistical Process Control, SPC, fashion having upper and lower limits on quality and risk. Out of bounds conditions are then monitored and managed. Under the DRP model, the structural shortfalls and the process of achieving them are assessed for risk.

The Develop and Test Sector: Also known as the Engineering sector. This is closely associated to the  execute, and control-monitor processes of the project management model. It is also aligned with the mobilize resources step in the DRP model. In this phase, the actual software design, coding, and testing is performed. The design process should be broken down into work packages aligned with Object Oriented Design, OOD, practices of encapsulation, polymorphisms, and inheritance.  In doing so, design relationships will flow with management practices like crashing and fast-tracking. Other activities include the actual coding and testing processes which are also part of the work breakdown structure. Having alignment between the management processes and technical practices such as OOD is essential for harmonizing this sector.

Plan the Next Iteration Sector: This is aligned with recycling the project management model or can also be part of a change management process. Likewise, it is aligned with the DRP model's analyze the outcome and adjust the reform for the next go around. Essentially, in this sector the  interim deliverables are assessed for their achievement towards the final objectives and any iterative objectives established during the previous Iteration. Any new ideas, updates, or capabilities are evaluated based on a change management plan. If approved, the scope is then updated and the baseline is adjusted in support of the new cost and resource demands. This cascades to adjustments to the work breakdown structure as well. Once complete, the process cycles again adding new features and any changes as the next iteration begins.  

Variations of Practice

Project managers have an array of tactics, techniques, and practices in their tool kits that allow for a wide swath of variation in management styles. In this case, I reversed the process spiraling inwards towards an objective. In most other cases, project teams may spiral outward towards deliverables.

Other practices and methods include Rapid Application Development (RAD), AGILE, and variations on SDLC.  For example, the Software Development Life Cycle model may be isolated to the develop and test sector of a spiral waterfall model in a linear manner having a requirements, design, implementation, verification, and maintenance phases. In terms of a System Development Life Cycle model the method can be applied to the entire iterative process having the planning, design, implementations, maintenance, and analysis phases.Whatever the approach implemented, project teams, stakeholders, and sponsors must find the ideal methodology for their organization. 

Commentary: Democratization of design is becoming a common practice today. Some designs have as much as 10's of thousands of people contributing. Timely reviews, evaluations, and incorporation of ideas is essential to markets that drive their products and services. This causes product development to be endless and increases the complexity of management. In many cases, project managers may never see the entire project through but instead work various parts of the process before handing off to other project teams.  Global 24 hr project teams are also becoming a practice increasing the complexity of management also. Having a solid understanding of the process and where your part of the process falls is important to success. 

In my experiences, I designed a software web application that was a democratization of design that saw numerous iterations. However, I was only involve in the first one and a half iterations. Due to pressing urgency the spiral model was compressed to the Develop and Test then Plan for the Next Iteration. The objective was issued as a simple directive, "Get the information flow under control!" I organized 44 cells and several agencies feeding information into a decision support process that compressed decision cycles from several hours or longer to a few minutes. Having knowledge of the process was exceptionally critical to the ability to manage the solution in short order in sort of a rapid application development way. I pulled modular blocks of management practices instead of code to guide the project.

In the end, project managers bring to the table a business management focus with their skills at managing projects and achieving organizational business objectives. Although, some companies seek project managers as a collateral skill to a primary skill of considerable depth such as coding or network engineering. In these cases, the company's business objective is not a focus  as much as the  technological design and performance. Once again, demonstrating how companies structure the approaches to suit their objectives and strategies.