Check out our IC Design Team coaching blog. To the blog...

I encourage comments from our readers by contributing to the "Speak Out" section. We will all learn through sharing of each others experiences in managing design projects.

A surprise on a project is when something unexpected presents itself to the team, forcing them to rethink or rework a completed step. Unexpected diversions are typically an accepted part of a design teams project progression, although accepting this as normal certainly deserves scrutiny. Reducing the frequency of surprises on projects is an area that will have a significant positive impact to your project predictability and development time lines. It is so simple, it really is.

Review the “No Surprises” goal to the left. The words circled in green, the who and when points, are typically done very well. Simple project schedules and plans will cover who and when aspects of tasks adequately. The expressions circled in red; the what, where and how terms, is typically where effort needs to be expended to migrate towards the ideal no surprises goal. In most cases these aspects of a task are left to “just happen” on a project, leaving the door wide open for a surprise.

What, where and how is about specific deliverables to a project. Any individual, at any point in the project, is either creating or receiving a deliverable. There is one key question that must be asked for each and every task on the project. That question is “Are the deliverer and receiver of each task deliverable in sync on detailed expectations of each other?” If they are not planned to be in sync, they will eventually get there, only after some painful surprises and task rework.

There is certainly work to be done to insure the synchronization of all the deliverables on a project. This is not the simple stuff that is captured in a schedule, it is documentation such as design guides or design travelers and it needs to be completed up front, prior to significant design activities commencing. You are likely to be of the opinion that there is not time for this level of planning. Consider this: you will spend the planning time and then some to accomplish this anyway, it’s just a matter of the level of surprises and rework you will face to get there. Do you want to plan to be in sync or let the team inelegantly and unpredictably work their way towards it?

Click Here to ask us more about dealing with the surprises you face on projects.

The team is trudging along, clearly focused on what they need to be doing and then in comes a possible feature enhancement or change. Is it necessary? Does it damage or enhance the business case? What will it do to the production release date? How much will it change die cost? These are some of the questions the business would have. If the potential change has come directly to the design team they will assume it’s a requirement and act upon it. Even worse some will assume it’s a necessity and others may not. The clear focus the team had on what they were doing is lost.

Unmanaged product feature changes produce a significant impact to design predictability. Managing change is purely about how you input, assess and communicate the change to the product development team. It’s a matter of formalizing a change process that insures clarity to the team as to a change being “under investigation” or “approved”. Formalized change management will leave a clear trail of feature modifications that have been requested, their impact to the project and the decisions about each one.

There are multiple sources of change for each project. The most well known source is from the customer. Also consider that the source of change may be from design, test engineering, product engineering, marketing and even the business itself. All of these potential change sources must be managed to insure clarity of the feature set for the entire product development team.

Failure to manage change will bring unpredictable schedule slips to a project. In fact, the source of the slip will be difficult to pinpoint. The team may have been quietly diverted off to a feature assessment, leaving the approved activities un-resourced. Or perhaps the team has decided to implement a feature that has no value adder to the product and it takes weeks to implement, wasting valuable development time.

It is in designs best interest to force formality in a change process. Without a process, design is left holding the bag on project delays introduced by unmanaged changes. You must pushback on any behind the scene change requests to elevate awareness and insure alignment of the change to the business strategy. Failure of design to drive feature change requests back to the business will result in uncontrolled/undocumented project slips that will be perceived as a failure in design project execution.

We Need your Input
This section is available to readers that have something to say about what I have written or general comments on IC design process management. Email me your brief letter and include your name(or anonymous), title and company for possible publication in a future newsletter.