Archive for the 'systems' Category

There is never enough time to design the production system for construction, yet there is more than enough time for making do. Simulations offer promise for changing that.

Simulation as a Tool for Production System Design

Thais da C.L. Alves, et al (presented by Prof. Iris Tommelein)

Using the design and fabrication of ductwork and ductwork fittings to They used Stroboscope¹ to model the process. They modelled the process on both deterministic and stochastic basis. The results produced large inventories on the construction site. By adding a "supermarket" rule² to initiate new work orders. Inventory dropped. They then ran the model by allowing variation. As anticipated when they ran the model they eventually got a stockout of ready work (in the 76th period). Based on this they reset their supermarket level.

The simulation models can be wonderful learning tools. Teams can experiment with production system designs before actually doing the work. The effects of variation on production system performance is highlighted.

1. Discreet event simulation environment developed by Julio Martinez, Ph.D. for the construction market. [ ⇑ back ]
2. The simplest form is to replenish stock when a certain level is achieved. [ ⇑ back ]

Residential home construction suffers from the same non-standard designs of commercial construction. But in residential construction there has been far too little time to do operations engineering to take the waste out. 3D (and 4D) design tools are changing that.

Concurrent Design for Production

James Folkstad¹

James recognized that design is a social process. As players change, the house will change. 3D CAD tools can enable that social process. Learning happens for individuals and may only reside in one person's head. Finding ways to share that learning across a subdivision is critical to driving the waste out of construction.

"There were so many slap-in-the-face problems to solve that we never got to the root causes."

James created a team of researchers-as-detailers to do the work of modeling design elements. As the team learned with the subcontractors they began to see they needed different tools for detailing and conveying construction documents. They couldn't build the models fast enough to keep up with framers and other trades. The company would not slow down to learn and avoid errors.

Early modeling took tremendous time. They have now learned to use methods to dramatically cut the time for creating objects and models. This is resulting in far more reliance on good details by the craft labor.

1. Associate Professor, Colorado State University, Industrial Engineering and Construction Management [ ⇑ back ]

Agile and Lean theories were used to design the mechanical and electrical construction processes. The success of a lean/agile design is to improve safety and productivity. The design incorporates automotive approaches for modular assembly with pulse-driven (paced) production. Has a goal to drive labor off the construction site to improve productivity and quality.

Design of a Lean and Agile Construction System

Peter Court, et al

"(Local) improvisations occur naturally unless you bring design intentions."

The system has three planning and coordination components:

• Modules (sub-assemblies)
• Components
• Consumables

Each has different work release and replenishment. Peter has learned to keep the implementation simple. He says, "Avoid explaining the theory."

Peter's lean/agile design will get tested next year when mechanical and electrical work begins. He promises to report on the results.

Complexity in construction stems in part from a willingness to accept unique materials throughout the design.

Process Benefits from Use of Standard Products

Iris Tommelein

The study is based on a refinery project in Houston, TX involving pipe spools. Iris used the Stroboscope discrete event simulator to model the process.

"Architects like to architect. The result can be complexity."

Iris is an outstanding teacher and lecturer. She made this subject captivating. After taking us through the logic of her simulation, Iris showed the effects from simulation of adding standard pipe spools. The surprising result was that project duration increased at an increasing rate as standard product is introduced. When product variety was nearly eliminated the project duration was cut by a 1/3.

Builders take note: there are tremendous benefits to increasing the use of standard products. Share Iris' paper with your clients and their designers. And if you get the opportunity, spend some time with Iris. It will be a memorable learning experience.

Buffers in production/construction operations protect down-stream operations from up-stream variation. That idea is well understood. The practice of setting and placing buffers is generally understood. This paper describes a simulation approach for capturing the nature of the project environment to establish buffers.

Design of Work in Process Buffers in Repetitive Building and Electrical Project

Vicente Gonzales, et al

The simulation was based on the lean construction simulation "The Parade of Trades". The simulation was applied to a case study for building homes.

Actual cycle times exceeded plan results for the unbuffered base case. This was compared to a buffered case. The buffer sizes varied for each of the operations in the sequence. Total cycle time was cut from 64 days to 55 days.

This looks promising. It looks to me that some simple tools are needed for project participants to design buffers on their project.

Application of Pull and CONWIP in Construction Production Systems

Roberto Arbula (Presented by Glenn Ballard)

"The intent to manage construction projects with detailed schedules long into the future is destined to fail."

Push, pull, and CONWIP¹ were described. The concepts were explained using the REBAR Production System for Heathrow Terminal 5 Expansion.

• Operating from a central mind to distributed specialists will be very wasteful.
• High variation and uncertainty makes long term detailed schedules useless for managing work.
• Installers worked with detailers to design the production system.

PPC improved dramatically over the life of the REBAR detailing and production.

The story of lean construction at Heathrow is incredible. The project is way ahead of schedule and saving $ millions.

1. CONWIP stands for Constant Work in Process to produce continuous flow. [ ⇑ back ]

Projects @ Work ¹ just finished a three-part series on People, Process, and Tools written by Alan S Koch. (You need a no-charge subscription to read the articles.) While Koch writes from the perspective of information technology projects his points apply equally well to other projects. These three articles offer a context for building your project organization including the systems you'll use on your project.

• The People Premium
• Processes for People
• The Role of Tools

Koch says what all good project managers know but too often forget,

"People are indispensable, but not perfect…Effective processes enable our most precious resource — our people — to work their magic…Tools are the key to making our people more efficient and effective at executing the processes that support them"

One of my favorite lines from the third article is,

"We do not need a tool for every job."

Koch could have said the same for process. What we do need is to select people, process, and tools that match the challenges of our projects. We certainly don't want more processes or tools than our capable people need. And if you are going to err on having more or fewer people than the project needs, then err on the side of more. Why? You can't improve anything without some slack capacity. Whether or not you plan to do your projects on a lean basis, you'll need enough extra capacity for people to respond to the inevitable surprises and to participate in continuous improvement activities.

Have a look at the articles then take a look at your current project. Do you have the people, process, and tools you need to succeed? If not, then make changes.

1. Hal is on the Editorial Board of ProjectsAtWork. [ ⇑ back ]

"I'll be happy if I never see another Gantt Chart."

Jim Rapoza writing in eWeek, Sept 12, 2005, seems to miss the old good days of project management, when project management software was just project management — Gantt charts and PERT diagrams. Project management features and functions have been grafted onto more general purpose applications from MS Office to wikis and portals. Jim acknowledges that the differences in project characteristics keeps us from using a one-size-fits-all approach of the ol' days — pick your system wisely. But it appears Jim doesn't miss much about the old systems. He finishes his editorial, "I'll be happy if I never see another Gantt Chart." Hear, hear!

Skanska Unleashes Work Crews using tablet PCs and Blackberries. Information Week, Sept 19, 2005, reports that Skanska is rolling out a "walking office", a construction site wireless network so construction supervision and project management can get anytime-anywhere access to electronic documentation and communication. This contrasts with the usual practice of needing to visit a jobsite office or trailer to refer to paper documentation, use fax machines, or request information from off site. Skanska is reporting a 20% productivity improvement. Skanska has adopted Constructware as their platform for a project management and collaboration environment.

I've been testing new software for managing projects. Basecamp™ is great! Go visit the site. Trials are free. The interface couldn't be easier to use. It's the right solution for small design projects. It's also good for consulting engagements. Get an idea of how different this is by reading their manifesto. It starts with

We believe project management is communication.

I could have written that first line. Have a look. Better yet, try it on your project.

Are you a project executive? Consider the lead to this article, Is Project Management a Crime?, published yesterday:

Is poor project management a crime? The answer could be 'yes' now that the Sarbanes-Oxley Act makes senior executives criminally liable for misrepresenting financial information.

Pay attention. If the following is true then we all better get in action.

What can project-based organizations do to help ensure compliancy with the Sarbanes-Oxley Act? If they do not already have a properly defined internal process for project management, then — according to Section 404 — they will need to implement one.

So what are we to do? Of course the author is ready with a recommendation: adopt an Earned Value Management System (EVMS). Huh? She cites Boeing and BAE Systems as two companies that endorse EVMS as best practice.

I've read the article three times. I'm beginning to think that the author actually believes what she is saying. So let's put her advice in perspective. The vast majority of projects involve just a few people. That's right, just a few people working for a short time. The last thing any of those people need is a highly structured reporting system for managing their projects. For the bulk of the projects EVMS will just add time and expense to the project without improving project performance. On the other end, let's consider the large projects. EVMS is a system designed for authorizing payments from the customer to the performing organization based on a baselined project plan usually created 90 or more days ahead of time. Large projects need a steering mechanism that adjusts to unexpected conditions. I've not seen an EVMS that will do that.

I doubt EVMS will satisfy SOX. Companies need more than a formal approach. Project and company executives will sleep at night when they know their project teams are managing their projects in the midst of the uncertainty of today's world. No over-the-shoulder tool will help them do that. They need an approach and skills that produces a coherent set of commitments to satisfy the promise(s) to the customer.

The Lean Construction Institute is conducting a workshop Implementing the Last Planner System™ in Atlanta on December 4 & 5. The workshop answers the question, "How do I make lean construction work for my company?" These workshops are not just for construction professionals. Lean project approaches have been adopted in defense contracting, software development, and engineering. This program is a follow-on to LCI's Introduction to Lean Construction. Check it out.

Awhile back I ran across a book authored by Riaz Khadem and Robert Lorber titled, One Page Management: How to Focus on the Right Things and Manage with One Page of Meaningful Information. If you are a One Minute Manager® fan, then you might remember Lorber as the co-author with Ken Blanchard of Putting the One Minute Manager® to Work. One Page Management was first published in 1989 and then revised in 1998. The book appears to be out of print, although used copies are available from Amazon.

The possibility of one page management (OPM) is quite seductive. Imagine…with one piece of paper you could manage your department, the company, even your project. The truth is OPM as described by the authors is really about three one-page reports that provide a means for bringing focus to the management of ones own accountabilities, ones direct reports, and the efforts of people in the organization. Everyone in the organization will have either one or three pages. That could be one big stack of paper!

The book is written in the typical one-minute parable style. There's a mysterious Infoman that just shows up or calls when needed. The other characters never learn his name, nor how to contact him. Sure, it's hokey! But, the book is a fast read and it offers enough detail to adopt OPM. At less than $10 delivered, you will get good value.

So I got to wondering…how could a OPM approach work on projects? And could it address the central issues of projects? As I explored the topic I began to conclude that the one page approach supports the role of management as offered by Fernando Flores in his PhD dissertation Management and Communication in the Office of the Future, p 56, Univ. of CA, Berkeley, 1982.

Management is that process of openness, listening, and eliciting commitments, which includes a concern for articulating and activating the network of commitments, primarily produced through promises and requests, allowing for the autonomy of the productive units.

The everyday issues for all projects are the same. What are we here to do? Who will do what by when? And how are we doing? I would have three sections to my one-page focus report for addressing those everyday questions.

1. Mission and Promises of the Project
   This is expressed in the client's terminology. What is the value the client will derive from having the project completed? Is that value time-sensitive? or cost sensitive? What could change that for the client? Exactly what have you promised to the client? How does the client come to understand those promises as the project unfolds? How satisfied is the client throughout the project?
    
2. Backlog of Project Work
   This could be similar to a Scrum Sprint Backlog. The backlog would be developed in detail as the project proceeds. Tasks would be negotiated with team members as other tasks are completed. It would be important to include promised completion dates for tasks so other team members can plan the mobilization of their work. It would track performance of completing what is promised on a daily or weekly basis.
    
3. Project Team Learning
   This could take different forms. One would be an on-going plus-delta on how the team is performing and conducting its affairs. Another way to engage is with the questions: How have we been surprised? What are we learning? What are we good at? What needs more of our attention?

I can see updating this one page as often as everyday. Section One provides the on-going context of the project. Having it in front of the managers and the team members everyday keeps the promise to the client from sliding into the background and helps bring coherence to the various interests of the team members. Section Two would change most often. The team would be updating it for coordinating with one another and for a continuing practice of planning. Section Three both reminds team members of the interest in learning and is the mechanism for sharing learning in the group. Each section would also include a tracking indicator showing project trends.

The construction industry has the practice of creating a daily report either by the site superintendent or project manager. The information has been standardized by the use of software packages. Most systems ask for data on weather, number and type of labor on the job, equipment in use, along with some notation of special events. This kind of daily report is not what I've been writing about. One page management is a guiding mechanism for conducting conversations among project team members and preparing those team members to conduct themselves both in coordination with others and as individuals. Used in this way, OPM becomes the instrument for the ongoing articulation and activation of the network of commitments.

The one page approach might be well-suited to a weblog using a template for structuring the content and a categorization scheme for later mining some intelligence. This kind of blog would be particularly helpful for the distributed team. A year ago I wondered Are Weblogs Tools for Business? How about Projects? then I proposed a Specification for Project Weblogs followed by a posting Project Weblogs Going Mainstream. This one page approach looks more promising to me than my take on the subject back then.

Who's up for trying this out? Let me know. I'll work with you by phone, email, or IM to help make it happen.

Here's my Proposal for a P-Log (Project Weblog) Specification.

Why the Interest in Weblogs?
I've been curious about the role blogging could play on projects. In October I did a posting Project Klogs: Changing Paradigms on John Udell's view of weblogs for projects. Udell claimed our tools and practices don't attend to the story of the project.

Projects fail. This is the usual case. We all know this. Attempts by the PMI to address this have not succeeded. It's time for something completely different.

Why A Specification?
We've been designing and redesigning the same collaboration tools for years. Ten years ago I used an early Lotus Notes database for project management. Back then and today the collaboration environments do the same things: provide status, track issues, and discussion. We can do those things with a p-log. But there are three critical issues that need attention that haven't got attention:

1. Uncertainty - the future unfolds influenced by actions of the team and the world that is unfolding around the team. Planning is the conversation for participating in the infolding.
2. Learning - the vast majority of knowledge is tacit. Projects are one-of-a-kind opportunities to share, deepen, innovate, …
3. Mood of the team - enthusiasm beats complacency, cooperation beats (internal) competition, determination beats resignation, and wonder beats arrogance. Yet, when mood is left unaddressed we get what we get.

P-logs are about the story of the project and the team. P-logs are for the team to take charge of the conversation of the project.

What's Next?
Perhaps this is too ambitious. Perhaps nothing short of audacious ambition will get at the underlying sources of project failure. I propose we do this together. How about a project conducted with a weblog for developing the p-log? (Thanks Joe for the proposal.) In the next few days I'll write about aspects of the p-log specification. Please join in with your comments and questions, suggestions and criticisms, and offers to build and use a prototype p-log.

Weblogs, like Reforming Project Management,
have proliferated. In a popular discussion group on Scrum Development, the proposed use of daily status logs attracted some of the best postings in quite some time. Many commented on the shortcomings of collaborative environments while others spoke of the value for enhancing knowledge-sharing, collaboration, and improved coordination.

In November 2002, Network World Fusion hosted a debate of the legitimacy of weblogs as business tools. Bill Keaggy argued favorably.

Using Weblogs in your business environment can increase employee communication and knowledge, save time and resources, and build reputation and confidence.

A blog can keep everyone up to date on projects without clogging in-boxes. It also can provide an archive of mistakes and milestones that could be shared with other teams undertaking similar projects.

Speaking for the other side was Mark Hurst.

There's nothing inherent in blog technology that will transform a business. A page of online posts, sorted reverse chronologically, just doesn't by itself change a corporation. If anything, the blog is inherently less effective than a more popular tool that companies have used for years: the e-mail newsletter.

One reader commented:

…the blog becomes a true knowledge management system. It's an archive of all the news and information that's relevant to them, which is searchable and sortable - including their comments and annotations.

When companies set up their own internal blogs, they need to convince people to take time from their daily work to put stuff into it.
Mike Masnick, President, Techdirt Corporate Intelligence

Or, should we really be considering a project management information system? George Sifri answered that question in December 2002 in a Builder.com article. Sifri says, "(P)roject managers often fail to deliver the types of information needed to ensure project success." Good start. Unfortunately, he adds, "(A PMIS) is able to provide upper management with adequate information about all the projects in the organization's portfolio." He offers these seven objectives for a PMIS:

• Enable the project team to identify and isolate sources of significant variances and determine the reason why a project deviated from its plan.
• Allow the project team to track the status of the work packages in order to determine the work that is completed and the work that is still pending.
• Help the project team manage project schedules by providing the basis for work package resource allocation and work timing.
• Interface and be compatible with larger legacy information systems.
• Help the project team forecast the impact of certain risks on time, costs, and quality baselines.
• Give the project team insight into what revisions to the baselines they need to implement, when they should implement these revisions, and why they are implementing these revisions.
• Integrate with the work breakdown structure (WBS), which provides the capability to report the status of the work packages throughout the project's life cycle. These reports include identification of the work package, its associated cost code and schedule, and the individual responsible for the work.

Sounds to me like Sifri supports the more structured heavy-weight approaches. The vast majority of projects lie in the middle between the unstructured use of email and the formal project management information systems. Let's explore a solution for the rest of us.

Tomorrow, look for my proposal on what a p-log should contain.