On my way back from a visit to our development center in Ukraine, I was pondering what I had learned about the use of “Agile” development work planning and tracking while there. (Wikipedia has a quick description of agile development work.)The teams that work on the various projects plan their work load by going through the requirements as a team, and then assigning unitless “points” to each of the requirements. The number of assigned points reflects the order of magnitude of the requirement that was presented to the team by the product design team; software development teams learn – over time – how many of these assigned points can be completed during a – say – four-week iteration, which helps them determine how much of the proposed features will fit in a new version of the software.
It struck me that the use of iterations, and trying to plan the amount of work that can be completed in an iteration of work, is quite similar to what we try to accomplish with what we call “stages” in the Virtual Design and Construction world. What often complicates the task of planning a Model Progression Specification is that it is hard to put a number of required days on a design, engineering or planning task. This made me think: what if we would assign “units of MPS work” to each of the element classifications in the project, per targeted Level of Detail? Would that give us a better way to obtain insight in the order of magnitude of work required to reach the next stage (thus deliverable) in an MPS?
A simple example of how I believe this could work: during a team meeting, the group agrees that “Foundation” and “Superstructure” corresponds to 20 and 20 units of work when the targeted Level of Detail is 200. The team also agrees that “Foundation” will be another 40 units of work for Level of Detail 300 and “Superstructure” will be 60 units of work.
Now let’s assume that the team is capable of completing 40 units of work per stage (for example, based on a 4-week stage duration). This means that “Foundation and Superstructure at LoD 200” and “Foundation at LoD 300” can all be completed in one stage, but that the work for “Superstructure at LoD 300” has to be sub-divided into more granular Building Element Categories and planned separately, in order to allow for planning the work in more than one state. When a high number of points is assigned to a Building Element Category at a specific Level of Detail, it also becomes clear where the complexity in the project can be found. Another benefit is that assessing the amount of work by assigning points as a group forces the team to communicate in an early stage.
Caption: Model Progression Specification stages are typically more granular than the image, but the sequence of events could read:
1. Conceptual design and feasibility study
2. Bid quantities, cost and schedule
3. Foundation detailed cost and schedule
4. Steel structure detailed cost and schedule
5. Concrete structure detailed cost and schedule
… (continued)
It seemed to me that the “Agile” concept, which is widely adopted in the software industry, would be capable of providing a tool set for MPS planning in Virtual Construction, too. The unitless nature of “points”, combined with experience that the team will gather by going through multiple iterations regarding the number of “points” that can be completed, makes this a flexible, yet powerful way to plan the work involved with all facets that should be included in the project data set as targeted by the Model Progression Specification. Tracking the number of completed points during the stage will make it easier for the BIM Manager to determine progress.
I would be interested in learning how teams are estimating MPS work today, and how progress is being tracked on a daily and/or weekly basis – let me know by posting a response!
Marcel
P.S. See how our agile development efforts are impacting the Vico Office release schedule.