Conventional Project

The previous two blogs demonstrated a way to employ agile techniques. At the top level the project was executed as a conventional project.  The project had gates, a steering committee and numerous schedule layers.  The organizational structure is balanced matrix (for the most part).  The organization is distributed both by function and geographic region.  The verification team discussed in the previous blogs, received components, both software and hardware. The hardware consisted of embedded parts as well as purely electrical, for example wire harness.

Collection of Sub Projects

The conventional project was responsible to deliver a new vehicle to the manufacturing facility.  This includes many smaller projects to deliver numerous of sub-assemblies that comprise the entirety of the system.  All of these sub-projects delivering these components follow the gates of the top level project.  That includes the agile like executed portions of the project.

A delivery to Conventional Project – Testing Results

The function area for the work was the verification and test group that is responsible for the sub-assembly and systems integration verification activities. The scope of the verification was larger than that illustrated on the graphics.  Specifically the company builds many iterations and permutations of the product and testing all instantiations to exhaustion is not possible.  The team had hardware and software in the loop tools as well as specialty fixtures to test sub-assemblies and the system. That includes testing on the end system, which in this case includes vehicles.

Large Projects are Really a Collection of Projects

In the end it is possible to view a large project as a collection of smaller projects, and in fact though the schedule, milestones and gate reviews may set the pace, it is possible to approach the specific contiguous area of scope as a unique project. Not unique in the sense of a stand alone project but unique in manner of execution that will most probably yield success.  I have heard the debate, agile is better than conventional project management.  Do not buy into that hype or way of thinking. The real answer is, it is not that simple, and it depends. It is possible to select the correct approach for the type of work and the assets available to the team (namely talent) and the risks associated.  It is also possible to mix attributes of these two approaches to produce other was to deliver the project objectives.