Management of Projects - Is it really working?

There is no question we have come a long way in the art of developing chips in the semiconductor business. The number of transistors we are managing to hook up and verify has swelled. The arsenal of tools at our disposal has made substantial advances in the complexity of chips we are able to take to production. Technically we are doing miracles! From a project management perspective we have highly developed approaches to the administration of projects, both in the tools we use and the methodologies we apply.

With all of these advances at our disposal we may assume that we have maximized our abilities to managing chip projects. One question we must ask ourselves - is it working? Are we able to meet commitments and produce revenue per the plan? On the surface we want to say yes, with the addition of some qualifications. In our gut we know the answer is no. How can this possibly be the case with all this technology at our disposal? When a commitment is missed our first instinct is to ensure the reason for missing the bulls eye rests somewhere outside of our control – a perfectly human response.

A project team is a group of individual contributor’s, all with differing sets of requirements that will enable them to contribute optimally to the project. Our advances in chip development are great in the technical arena. The missing link in the ability to deliver is commonly related to the non-technical aspects of managing a technical community towards a common goal. We are engineers and everything in our world is about science, about black and white, about everything reacting the same way to the same set of circumstances. That mindset is just plain ineffective in aligning technical individual contributors towards the achievement of a common goal. When dealing with people, nothing is black and white.

Here’s an interesting concept – individual team members know what is not working for them on a project and they have known this for a while. Create a candid environment where this information can be gathered one on one and learn what keeps projects from flowing optimally; understand the reasons for project surprises. Take action to address each item found and remember that they all matter to someone. A project is not merely a system to be managed; it is a collection of very individual contributors with naturally human traits. Believe in this by addressing the personal region of a project and reap the benefits of a new found freedom from project surprises.

Development Process First - Organization Second

Is your development process supporting the needs of the business or the needs of the organization? If there are many success stories, celebrations and goal achievements in organizational silos while the product misses on revenue objectives, the development process is supporting the organizational needs, not the business. Ouch!

An ideal development process is one that is derived to fully serve the needs of the business model as the primary objective. Accomplishing this can only be achieved by minimizing the organizational silo influence through a hierarchical top down approach, yielding a top-level process that is independent of any organizational structure influence. Please read on to learn about an approach that will enable a development process that focuses solely on supporting the business strategy.

Start off by identifying a core team that can fully represent all disciplines within the organization. Next I would suggest a establishing a dedicated room with large sheets of paper on one wall and an ample supply of blank sticky notes that will be used to represent the process steps. At the far left is a new opportunity and at the far right is volume production.

Now with the full core team, fill in the steps between opportunity and production using a sticky note for each, leaving any consideration of organization out of the diagram. Place the sticky notes in order from a flow standpoint and once agreement is reached, fill in the flow with lines and arrows.

This activity may span a several week period through multiple sessions. I would suggest others outside the core team to have "read" access to the room. However, any changes proposed from outside the core team must be handled through a core team member during a regular session.

Once this activity is completed and consensus is reached the final top level process can be captured and farmed out into the individual organizational entities for detailed process development, again using the same approach. The next level of the process must fully support the top-level process within each of the silos, paying particular attention to areas where cross-organizational flow is required.