BIM and XPM: A Made Marriage - Part 3

Part 1 and Part 2 of this series introduced you to a new light-weight management method based on Agile and XPM planning methods. In Parts 1 & 2 I told you I would tell you how we used this theory so in this installment I'll make good on the promise.

We started out trying a piece of web-based tracking software which is open source. We abandoned it for a couple of reasons, the biggest reasons being a serious bug in the software and a lot of terminology specific to software development. As a second attempt we backed off and started over with a stack of 3 x 5 cards to represent the elements of the plan from Releases right through to the Tasks / Tests. Later on the team wanted to use an online solution and we agreed on a simple online forum as a platform. It meant a little more manual work than the previous online software, but we found it worked just as well and was simple to use and it didn't have all that foreign lingo of software development. We were free to make up our own language. I'll also say at this point we also tried spread sheets as an alternate to the web forum, but that was just too unwieldy and didn't have good multiuser support. Spreadsheets really are built for single authors. We did find the spreadsheet was OK as an alternative to the 3x5 cards for planning.

We created several different structures in our forums but the following became our standard of practice.

A list of categories called Active Projects, Completed Projects, General Discussions, and Food for Thought. We used General Discussions for topics that weren't germane to the production of any single job, but something someone wanted to pass along as a supporting thought or reference for the general practice. Food for Thought was used only for discussions that directly related to the management practices and how they might be improved or extended.

Next under each forum category we had the projects themselves. Under these we had children forums for Planned Work, Current Work and Completed Work That looked something like this.

So you can see a very simple mechanism implemented in a simple to use software tool like a forum, gave us the majority of the functionality needed to organize our work. It was easy to move the elements of the discussions as well as the discussions around as their information matured.

It only took us a very short amount of time to teach anyone in the office how to set up and maintain this organization method so we used the junior team members to do this task. That way they got used to the tool and how it was used every day.

The Language of the Forum
Next we had to create a lexicon and grammar to organize the information at each level. We tried a lot of different solutions with varying results. We finally gave each project team some latitude on their choices due to the preferences of team leadership and the complexity of the project. We had a range of organization that had little if any sorting string thought to some that could organize the views by selecting string or substring values along with numbering schemes that produced views with only a very selective result. For instance some teams chose to use a title string that looked like the following organization
[completion] | release | Iteration | story | task | [Responsible] | title and looked like....

[y/n]2.3.15.100[] Model interior sound partitions

If someone only wanted to see incomplete release 2 tasks they would look for a string like "[n]2.*". Or all the incomplete story 15 tasks with "[n]*15.*" If someone wanted to see all the work they had taken charge of they could look for "*[aa]" if their initials were "aa". So you can see there is a lot of flexibility in an open string and search tool to quickly create searches to display results. Our forum also had a listing view to show all the past activity as new or changed information in the forum, which made it easy to watch the work being completed without having to do a lot of searching.

We also included information in the body of the task / test entry like when it was due as a calendar date [11/15/11] and any reference documents back to the Project Notebook or other web resources before the task description. Work completed was created as a reply to the forum entry and signed / dated along with the hours used to complete the task and test. Both the Task and Test portions had to be completed before the work was marked completed. 

The wiki project notebook
The companion to our forums was a wiki organization which we implemented using Mediawiki. The wiki held both the higher order project information like clients, contacts, project budget and schedule information as well as specific information regarding selections for materials, assemblies and all the other design requirements information. In addition we used template pages that organized much of this higher level information so all a manager or other assigned team member had to do was select one of the template documents, duplicate it in their project and then fill in the blanks as needed. This normalized both the information and the organization pattern for this kind of information and gave each element a url page location which could be used in the forum to point back to when needed. So the wiki became the project notebook and it was uniformly accessible by anyone at anytime from anywhere they could get a web connection.

We also had sections in the wiki to assist project work planning teams to easily create stories, and task collections by creating lists of common stories and tasks / test combinations. They could cut / paste the needed information out to make it easier to create the forum entries. 

So there you have the core of our tracking and documentation methods. Nothing fancy, but it works and it is free. There is enough flexibility in the methods to accommodate a lot of differing need so if you need a simple implementation, pare off what you don't need and use the rest. If you have more people and work to manage, you can step up the organizational framework to meet your needs.

Advantages
This level of project documentation made it easy to add new members to the team. They only needed to read the information necessary around the work they were assigned to. If they needed some background on how the model was organized the BIM Execution plan gave them that info housed in the wiki and referred to in the tasks / tests they would work on. Instead of having to brief someone for 20 minutes or more, it took about 5 minutes for a new person to join in and get productive, and that was without a senior team member giving them a briefing. Yes this did take some time, but it kept people focused on their work. Work that was needed was completed in timely manner. Work that was not needed yet didn't get worked on. And tracking the completion of work or where there were issues were easily identified and solved quickly by the team or an outside source when needed. After setting the expectations and training this system was very effective in keeping our projects on track and eliminating waste.

I hope this helps you understand how we organized our work. In Part 4 I'll share the measurement indicators we used to track progress. Until then remember "Collaboration is the glue of success."

Now on to Part 4, the last one

 

This article continues a String of Connections between practice management, BIM and Agile management practices.