|
|
|
Intro -
Overview
"On projects – especially those
creating something new – the machinery that codes and decodes direction is
dangerous." |
Jim Coleman has written and published numerous articles about managing projects. Abstracts are provided below.
Complete articles are available for each abstract. "We thought you meant . .": A Case for Being Clear Confusion costs more than mistakes. A mistake merely misses success; confusion doesn’t even recognize it on the way past. A mistake is 1+ 2 = 4 ; confusion requires higher math. Large projects are fertile ground for confusion. Customers hand requirements to companies, who hand them to projects managers, who hand them to project teams, who work on their parts then hand them to other project teams, who work on other parts then hand them back to project managers, who hand them to customers. That’s a lot of handling. We know the path from what-is-meant, to what-is-said, to what-is-heard, to what-is-done is imperfect. On projects – especially those creating something new – the machinery that codes and decodes direction is dangerous. Toss in multiple languages, inexperienced teams, complex sourcing strategies, and modern management methods and the route becomes downright perilous. This article is about being clear. It doesn’t promote massive overhauls of business processes and systems. However, it does promote expecting all who participate in projects to give clear direction and to clarify what is received. Read the complete article (215) TOP Project teams rarely run into an executive’s office and announce, “We’re in trouble!” This small but important piece of information often comes through the ventilation system. Teams that plan and manage well usually catch problems early enough to deal with them before they become trouble. Other teams don’t see them coming or even recognize them when they do until the project is stalled and on the side of the road. Executives need to smell trouble before they get the roadside call. There are often many unwitting signs that all is not well. When project managers say things are “going great,” that’s the first sign. Great projects never “go great.” They struggle with every detail and find the best-of-imperfect answers. There are less obvious and more telling signs that executives need to read. Teams often feel they need to please rather than ask for help. Executives who foster this notion in word or deed are asking for trouble. Those who sense and deal with problems early and constructively will encourage teams to do the same. Request the complete article (212) TOP Important projects can find themselves in deep trouble. They reach a point where there’s simply not enough time or money to complete them satisfactorily. Confronted with this fact, executives must continue, stop, or salvage what they can from a messy situation. Deciding to salvage a project requires courage. Some original objectives will likely be compromised to meet others. Critical actions must be taken to create new project terms.
The risk of salvaging a troubled project is that if it still fails more is lost than the additional money spent. The good faith and confidence of all participants are violated. If it succeeds, more is gained than success. All concerned have witnessed the triumph of good management over adversity. They may reshape how future projects are done. Request the complete article (209) TOP When suppliers do projects for customers, they share two relationships. The project relationship is focused on successful completion of one venture; the business relationship, on other current and future ventures. The relationships are separate but symbiotic. One can jeopardize the other. Project managers for customers and suppliers should assure clear divisions of responsibility and interface requirements between their organizations. These are the fences that make good neighbors. These fences -- like the organizations that attempt to adhere to them -- are imperfect. When requirements change or can’t be met, there must be room in the project relationship for consideration and conflict based on constructive engagement, not a personality slug-fest or, worse, silence. Customer executives and supplier account managers recognize that fences can fall into disrepair or performance can fall short on individual projects. Their project representatives may lack the perspective to resolve these conditions in a way that keeps the business relationship strong. Their intervention can avert winning those battles that lose more important wars. Request the complete article (205) TOP Many product development projects don’t go well. Companies get discouraged about their ability to actually deliver a product on time and budget. When company executives finally find a team that gets and keeps a project under control, the euphoria may obfuscate other factors that also drive success. Product requirements describe what should come out of the far end of the development cycle. They are often poorly described by those who commission the project so the project team – with all best intentions – fills in the holes during the development of detailed specifications. These may be technically right but not conform to the original intent. Technology decisions that should be driven by product requirements may have a reverse affect. They may seduce the team into adding or changing product features. This may cause further deviation from the original intent. Project teams may be delivering bad products well. Executives need to maintain their focus on product success un-blinded by project success. The roles of the project manager and executives need to be updated to assure that strategic and tactical objectives remain in synch. There are several ways their relationship can be retooled to avoid problems. Request the complete article (201) TOP Projects require that people be productive both individually and collectively. Being more productive individually requires aligning ourselves with work. Being more productive collectively requires aligning ourselves with others. We waste our own time for reasons too numerous and personal to innumerate. We waste other people’s time because we can’t or won’t see how what we do influences others. We burn budget and hold projects hostage through our actions. We start work too early, don’t coordinate deliverables, don’t deliver when we should, and spin our wheels too long. The result is project teams that don’t deliver what they are capable of and spend too much money doing it. Project managers’ jobs include assuring that team members can and will be productive. There are ways to accomplish this that don’t add even more wasted time. Request the complete article (182) TOP Saturn's Vision for Program Management In 1985 Saturn Corporation was founded to produce an American-made car to compete head-on with Japanese vehicles in the area of cost, quality, function, and service. General Motors knew they needed "a different kind of company" with a different kind of approach to the business of developing and manufacturing cars. The challenges associated with developing and implementing any idea in a large disparate organization are considerable. Introducing a program management approach at Saturn is no different.
This article provides a snapshot of Saturn's vision for program management:
its organization and how work breakdown structures and schedules will serve
its needs. It also describes the implementation strategy, challenges faced,
and what makes this approach different. Developing anything new is complicated: the product, the parts, the testing, the tools, the production facility, all need to support a single set of objectives. Like a relay race, development teams pass their drawings to others, who pass theirs on to others. And so it goes forward, driven and burdened by the need to be right and on time. An automotive development program multiplies the complexity. The product is developed by many teams, whose parts and tools are designed and tested by a maze of other teams, who deliver these to plants that must be ready to manufacture and assemble on time. Or else. Critical path method schedules can be supplemented by other planning methods. The cumulative event curve offers managers the ability to answer questions about the rates of progress that schedules alone cannot. This article outlines the methodology for developing, maintaining, and using event curves on automotive programs. It also provides five examples of how these can be applied to meet the needs of different kinds of managers under different circumstances. Request the complete article (171) TOP |
|
|
Copyright 2001-2006 jhColeman LLC. All rights reserved. |
