Lean Startups and the Flow of Value-A lesson for the AECO Sector

Dave West recently wrote an article in ProjectsAtWork.com's June issue  that I immediately identified with. In fact he almost writes a parallel post to one of my original posts which is also one of the all-time favorite posts here on this blog. BIM & XPM-A Made Marriage.

Dave is currently the Chief Product Officer at Tasktop and one of the foremost industry experts on software development and deployment. He has helped advance many modern software development processes, including the Unified process and Agile methods. As such, he knows of what he talks and it is a strong validation of the work I discovered somewhat by accident and happy circumstances over ten years ago.
Please read Dave's article here

Dave's mention of the Lean Startup movement, that is going through companies right now lead him to some interesting conclusions. As a mentor at our local Gangplank chapter in Tucson and having been through several Lean Launchpad  Startup workshops, I can attest to the parallels which Dave highlights. For the real focus on the Lean Launchpad is creating value and validation of a new idea using the minimum of effort to seek the greatest return. In a Lean Launchpad we don't go into big elaborate tests, but use simple tests to determine if an idea has merit in the marketplace. For me that was natural. I have been doing that in design practice for quite a while. Tweaking the context was easy for me to see how focusing on creating the greatest value using the least expensive means possible gave way to determine where the maximum effort should be spent as an idea matured and became validated.

How did all this resonate with me? I started using a variation of XPM and Agile back about 10 years ago in the design profession of architecture. The close parallels of SW development and working in the built environment design are quite scary. For that reason, and that it focuses on the value stream of information, the above rationale delivers very good results.

On my early journeys in this endeavor to find a better way to practice design I looked for ideas which would bring the design process together more efficiently. Since I'm not a purist on either the lean or agile side I just looked for what worked well and could be repeated over and over with consistent results. Creating a flow of information which delivered the value needed for timely decisions became our mantra. It reduced rework, it focused on the issue(s) at hand and set all others aside and above all was guided by the principle of keeping the end goal in mind.

Often, the project's end goal was modified along the way due to inconsistencies in assigning value in the beginning. But that is to be expected, since not all the value is known before a project starts. Discovering that new areas of value harvesting made more sense than staying with original ideas we were able to keep the project expectations in line and the Owner happy. More times than not, the final results were better than anyone would have imagined going into the project.

Who was responsible for delivery, everyone. If someone working on the project did not see it was their project to deliver value, they often were removed or isolated out to minimize their damage to the rest of the producing team.

As you can see, adaptability, collaboration, transparency, autonomy and focus on value were key components in our success.

Always remember "Collaboration is the Glue of Success"

NoSilos.com
Collaborative Construction Blog

This article is a continuation of conversations about how delivery of professional services in the Built Environment can change the way business is done. This article focuses on the change in focus from functional activity to delivery of value in every action and the need for all participants to own their part of the project delivery. It is a continuing String of thought with connections to project management, project delivery methods, change management and the continuing evolution of business delivery in our marketplace. 

Top Five Most Read Articles at this blog.

 Seems people over the past year were really interested in the lean topics but just as interesting three of the most popular articles came from pretty early on and all three were tied to BIM in some way. But one of my favorites about the Design Age is still there in the top five.

Feel free to chime in about your favorite. Oh, and if there's something you would like to hear about more let me know that too. 

And thanks to everyone for your readership and support. 

Andrew

Remember, "Collaboration is the glue of success."

Chaos and Change are Brothers - Part 2

Recently a group of really bright folks, Dawn Naney, Clay Goser and Marcelo Azambuja posted a new document entitled "Accellerating the Adoption of Lean Thinking in the Construction Industry" which deals with the issue of adopting lean management theory within the construction industry. The following is part of the response I posted on the LinkedIn discussion group which Dawn posted. I thought after I wrote the response that it is just what I've been thinking about writing as Part 2 of this series, so here goes. I hope you enjoy the read. Of course you know Collaboration is the Glue for Success. If you haven't read Part 1 of this series then here's the link.

I would agree with the findings of the authors, but I contend there are a few of us in the business who have been talking about how to make the change stick and at the same time doing something about it. Up to this point we have been pretty quiet about it. (Yes gentle reader, I'll have much more to say here in this blog over the coming weeks.) The root issue revealed in the adoption curve that Gartner espouses, is the lack of efficient change management. When we stop

BIM Without Collaboration Doesn't Measure Up

A couple of weeks ago Ted Garrison of New Construction Strategies interviewed me on one of my favorite topics, collaboration in context of the use of Building Information Modeling. Here's the quick synopsis Ted used when he posted the interview. Just click on the link below to listen. 

“BIM isn’t about drawing lines, it’s about building buildings virtually;” declares Andrew Abernathy. As a principle in Collaboration Consultant, Abernathy provides expertise on project management collaboration. Listen to him explain how BIM can improve your projects.

Listen Now

This  post is a part of a String of posts part of a conversation about design and virtual design and construction and BIM

BIM and XPM: A Made Marriage - Part 4

So far in the previous parts One, Two and Three of this series I've introduced you to an alternative work management method using eXtreme Project Management theory (XPM). XPM is a variant of the Agile light-weight management movement. The roots of this management theory caught hold in the software world and has moved into other business domains. If you want to change your management to fit more closely with collaborative efforts and use BIM in your practice, then you need to give XPM a very close look. It has a lot of advantages to offer and gives a lot more control to the people actually doing the

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. 

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

BIM and XPM: A Made Marriage - Part 1

Prelude...
Since writing this article back in April, It is ranked #2 for the number of all-time hits on this blog. I'd like to encourage you to read all four parts. The hook is I reveal how all this works in the later parts. These lightweight management theories will radically transform your business and professional practice. If you want to see more $$ at the end of the year and create a better working environment, then I strongly advise reading all of the series. aa June '12
 
Introduction
BIM and XPM were made for each other. BIM authoring tools of just about all forms are characterized by elements or families which have some kind of data construct attached to the graphic elements. The graphic elements can be driven by parametric data or not. Not surprisingly, the elements are organized in large categories which roughly approximate the organization of the construction material sets needed to erect a building such as foundations, floors, walls, ceilings, furniture, casework, equipment and the like. Views are organized in a way that traditional document sets have been assembled for decades such as plans, elevations, sections and tabular schedules. Since the model is 3d there is also a new view for 3d perspectives, isometrics and other similar views. A very modular and structured way of thinking.

Most importantly from a work management point of view all these elements and views are very atomic and largely independent of each other. They can be created with or without any data or graphic content in them, or at the very least only the barest of information or graphics as place holders waiting for more specific information. The other important

Complex Problems and Light-weight Project Management

I'm currently working on a new project which aims to reexamine one of the key components of our economy and how it might be modified to reduce waste, risk and in the process increase productivity and profit. As you might surmise, it is connected to the built environment.

I was reviewing some thoughts and notes with one of the team members last evening and the topic of  light-weight project management tools came up. If you aren't familiar with the term you probably have heard about Agile and Lean methods. They are the two leading PM methods classified as light-weight methods. Each has their own areas of application, one does not substitute for the other and there are dialects within each of these major classes. On the Agile side are two major dialects called Scrum and eXtreme Project Management (XPM). Scrum being the oldest and eXtreme being younger and having Doug DeCarlo as it's creator and proponent. Scrum came out of a skunkworks kind of environment and is almost totally focused on software development where Mr. DeCarlo's methods are used largely in the software world there is a growing interest and adoption of his simpler more transferable concepts in other domains.