Chaos and Change - Part 3 - Lean, Agile and Mgt2.0 Can Succeed

This is the third article in a series about Chaos and Change. How they change our working worlds and how we can gain come control of the chaos. The previous installment was titled Chaos and Change are Brothers - Part 2  I suggest you might want to go back and catch it as well. 

The following is a reply I posted on Fierce Healthcare's discussion area. The site is one challenging healthcare folks to stay up with the latest developments in their fields. I came across Susan D, Hall's post in a LinkedIn Group and thought it interesting. While all of you know I'm a big supporter of better management and highly collaborative frameworks for companies, I thought it appropriate to clear the air about change initiatives and their chances to survive and make have some permanent change as a result. The following is my comment on Susan's blog post you can read here entitled, Lean leadership in healthcare: What does it take? Of course my comment there is posted here, but please read Susan's work as well.

Your Brains Work Best When They Can Turn from Failure to Success

Susan,
As an evangelist for better business principles which are more lean, more agile and responsive both internally and externally, I applaud your efforts in healthcare. Unfortunately, the cards are stacked against you. J, Kotter in 1995, Turner and Crawford, 1988 and Prosci, 2005 all indicate that only 30% (at best) of projects introducing change in organizations have reported any real measurable change. If you look at the flip side, that's 70% failure. Now I'm

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

7+ Reasons PM's Don't Improve Efficiency or Productivity

Many of you know I subscribe to the art of stealing and transforming ideas to get new results or perspectives around difficult problems. It's just an axiom of our world, 'nothing is new under the sun.' Did you know they had vending machines in Pompeii? Amazing!

In a recent article on Projects@Work there was an article closely titled to this entry, but it related to CEO's. It was written by Mike Beard who is a pro at Project Management. Mike was writing about the folks in the C-Suite, but let's take a minute and step back to take a closer look at the everyday activities of project leaders and managers. I would contend that Mike's seven reasons falls squarely on the shoulders of just about every person who managed a project or held some kind of management responsibility. At sometime all of us have been party to one or more of these seven reasons. It's not an indictment, it's just the way we are as humans. It is also not an excuse for the behavior to continue. I would hope all of us are working to become better practitioners in our chosen fields and have some ability to look at ourselves candidly to measure how well we perform and act. So let's look at Mikes' Seven Reasons quickly and see how we measure up. Oh and I've added a bonus reason at the end for you.

1. We have met the enemy and he is us: (my paraphrase). Yup, I'm my own worst

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.