BIM and XPM: A Made Marriage - Part 2

Recap
In Part 1 I introduced the concept of using Agile management techniques in a BIM-centric design / construction practice. After looking at the article I found I made a lot of assumptions and you know what that usually means. I have to apologize for the assumption you would know about Agile, or XPM and how those light-weight management tools would or could work in a design-centric work environment. So to make up for my oversight I thought a quick primer on what the basic parts of an Agile / XPM environment looks like, as we implemented it. One caveat here, if you are familiar with these
management tools you will find I have changed to definitions somewhat. Why? Well these were and are the definitions of how we implemented and used the theory and some of the definitions changed with our experience and application. But that's what agile and XPM are all about, Try, Measure, Adapt, and keep on perfecting the tools as you work with them over time.

So let's begin with some limitations. The first are Constraints.

 Constraints are always with us. They limit what we might be able to do otherwise in a perfect world. These constraints usually create some kind of Risk

 Too often we try to ignore risk in our planning, but eventually it will catch up with us. Usually it creates a delay or a change in scope and as mentioned above is usually driven by one of the Constraints mentioned above.

I have used the word Phases to describe the elements of planning we used in our implementations. Phases is a word many of us in the AEC world understand, but in the agile / XPM tools domain they can take on some different aspects.
Let's begin with the overall Project.

We developed a template for each of the descriptive documents and held them in a wiki framework. It was pretty easy to create these documents in an afternoon by reviewing contract documents and conducting some interviews with an Owner's representative to confirm any items not covered in the service agreement. The advantage of pulling all this information together is the openness and access to the information for the entire team. This information is typical of any good project management description. One thing that could be added here is a BIM execution plan. We often put this document in this group as a supporting document for the Project Plan.

Now to the specific planning and measurement elements. The first is the Release Plan.

There is a lot of literature wriitten about the Release Plan, but in our experience we found there were major releases at the end of all the traditional phases of work such as Schematic / Preliminary Design (SD), Design Development (DD) and Construction Documents (CD) as well as Contract Administration / Field Observation (CA). If we provided Master Planning (MP) or Feasibility Studies (FS) we added Releases for those as well. If we were collaborating with a builder we often added more releases in the SD and DD and CD phases to make sure we were progressing and making sure materials, equipment and constructability was proceeding as planned. Up to this point you might be thinking this isn't any different than what we are already doing, and I would agree with you. 

But now we introduce a new planning idea, The Story.

Once the Stories are started the work needs to be accomplished. By looking back at the Release Plan and the initial Stories the team decides what work will create the most value for each period.

The combination of the Story and Task/Test pair are the heart of this planning method. Stories are the backbone of organizing work. They will be refined with additional Task / Test elements to complete the work defined in the Story scope. Note that this element of the management tool is built around continuous improvement loops. Models can take of advantage of some of the new testing tools available like Solibri. It is important to make sure the Tests work correctly. In the best situation, the working team should be able to test their work as they complete it, making sure the model does reflect the design and performance requirements.

As we worked through the process we found there were repeatable Task /Test subsets and even some entire Stories that repeated, so we borrowed the concept of a Prototype set to save time and increase quality while reducing waste in the planning time. 

That's it. Now you have all the pieces. In Part 3 I  will share with you how we used the parts to create and manage a work plan from start to finish. This article continues a String of Connections between practice management, BIM and Agile management practices. 

On to Part Three