It’s not our Fault

When describing the reasons for a project being late have you ever heard the reasons come around to “It’s not our Fault, if only so and so would have...”? Oh come on now, I am sure that has occurred a time or two or more. Have you ever used the reasons yourself? I certainly have in my career. Why is this done? Its just good old human nature, the way we tend to be wired. It let’s me justify continuing on in a problem filled environment and not have to take responsibility for it. Can it be changed, or better yet should it be changed. Yes to both questions, without a doubt.

Without an emphasis on execution issue resolution nothing will ever change. And that means stepping up and taking ownership. You want somebody else to step up and own it don’t you? Of course! What happens when nobody steps up, keeping the blame game alive and well? Things stay exactly as they are and you wake up some day wondering where your business went and then sometime further down the road you wonder where your job went?

If you want to protect your business and your job it’s time to take ownership for problems that you are facing in project execution. The truth is everyone plays a role in non-ideal project execution. The true leaders will step out front and take ownership. Come on, go ahead and stand out from the crowd and get the common, systemic issues put to rest first and then dig deeper. Never stop digging. Get out of your design silo and look at the big picture. Drive changes that will promote agreement and communication of each task what, where and how; the essential ingredient for predictable project execution. Make a difference!

Revving up your Lessons Learned Methodology

If your lessons learned process is not making a visible impact on future projects it might be time to make some changes to your process. The most common forum for project learning's is post project meetings or postmortems. Enriching the effectiveness of lessons learned should include formal project audits, project diaries, team member interviews, checklists/travelers or the use of an external facilitator. I will expand on a few of these additions below.

Project Audits
Project audits are merely a formalized approach at evaluating a projects execution. Where things did not go as planned, root cause analysis is critical to identify the remedy for future projects. Audits are much more time intensive that the standard postmortem approach, providing a commensurate improvement to the exposure potential of project challenges. A 3rd part audit will provide the greatest benefit due to the lack of any preconceived notions about how the project went.

Project Diaries or Journals
In this case everyone on the project would maintain their own journal of thoughts, ideas and problems throughout the project. This increases the effectiveness of lessons learned since no ones memory plays a role in the quality of the assessment. I don't know about you, but for me anything that removes a dependence on memory is a good thing. This one is pretty simple and effective, assuming you can influence your team to write things down in a nearly real time fashion.

Team Member Interviews
I would merge this in with a formal project audit to improve the depth of the assessments. During the interview you need to craft questions that would enable project challenges to bubble up during the discussion. Most of the effort here is the preparation of the high quality, challenge uncovering questions to pose. There is a lot to learn from the members involved in a project.

External Facilitator
Having someone unbiased by the project will always provide a much clearer vision of how the project went. For this reason I would suggest using someone outside the project to facilitate postmortems, audits as well as interviews. This also brings a fresh perspective to the analysis, always a good thing.

One aspect of lessons learned that is extremely important is this. Any item identified out of lessons learned must generate a specific action that will be tracked to closure. A lesson learned will have little value if it does not lead to a decision and plan for incorporating it for future projects. The objective is not that a lesson has been captured; it is how you have changed your development process based on the learning. Lessons learned must be an action-enabling activity!

Gathering Statistics for Project Execution Improvements

Below is a link to a short two question survey to gather information about improving project execution in the semiconductor industry. The survey specifically is querying for reasons why organizations may not be improving project execution and also ranks the key sources of project delays or failures. It should take less than 5 minutes and upon completion you will receive a link to monitor the survey results.

PLEASE - Only take this survey if you are in the semiconductor industry.

>>Off to the Survey

An Agent for Change

Many IC design teams know where the major bottlenecks are in getting a project completed, yet pretty much continue as they have. There are usually some ongoing activities happening but they are typically back burner projects that are easily derailed for “real” revenue producing project. I see this happening all the time, with the primary reason being a lack of time and/or resources. The message spoken is that “improvement is mandatory” while the message supported is “not now”.

It would seem that the only way for real progress is to have a dedicated resource responsible for bringing about improvements in the development process. This resource is hands off for revenue projects; their only mission is driving a continuous, never ending path to improvements. They are the “Agent for Change” or “Change Agent” and their mission is purely in driving and leading change for the better.