Consider the development process you use today and how it was derived. Was it a broad-spectrum view of what needs to happen to generate new product revenue or was it a set of processes derived by each of the organizational entities within your business? Taking an honest, unbiased assessment will most likely yield the latter approach as the most correct answer.
Assuming the processes were created in each of the organizational towers, what do you believe the focus for each process was? Honestly, it depends on the function of each. In design the focus was on a tapeout. In product engineering it was product qualification. In test it was development of characterization and final test programs and hardware. For project management it is the development of a timeline, cost analysis, a business case and the steps to synchronize everyone. Marketing is paying attention to customer requirements and what it takes to secure the socket win. And of course business/operations is paying attention to revenue, margin and the timeline.
Now consider the process deliverables and interactions for each organizational entity. Are they really aligned to the only objective that matters - profitable revenue? So now I would ask - Is the development processes actually focused on the business requirements? In reality a few members of the development team are focused on revenue while the majority are paying attention to their more localized goals and objectives.
Here's a key question to reflect upon for your organization - Is the development process supporting the organizational structure or is the organizational structure supporting the development process? In an organization where the development process is primary, the project decisions, risk analysis, objectives and communications will be based on the big picture - business revenue priorities. Where the organizational silos are foremost, the development processes will be fragmented and disjointed with objective success not consistently supporting and enabling the business revenue goals.
Friday, July 31, 2009
Is your Development Process Targeting the Right Objective?
Posted by Jeff Jorvig - IC Design Leader at 7:01 AM 0 comments
Wednesday, July 22, 2009
The Big Secret – Costs of Inefficiencies
We are going to be late! The news kicks off an energy explosion in attempting to regain the slipped time, often leading to some incremental gain with a rare exception that the project is fully back on track. The conclusion of this project saving frenzy typically involves an emphasis on how this slip is not acceptable and things will need to be better next time.
The reality is that specific actions to discover root cause and implement changes for future projects are rarely defined and tracked to conclusion. After the “catch up” flurry diminishes the team goes back to a pure focus on completion of the current project and any prominence on improvement quickly fades. Why? Time and money is the most common reason to “put off” an effort where project execution efficiency is the objective.
During this current economic downturn the emphasis on costs is at an extreme level, although mainly focused on the most visible expenses. How do costs related to project inefficiencies figure into expenditure savings? Probably fairly limited due to a lack of visibility – they remain behind the scenes and are rarely face head on. Here’s an interesting question to consider – What is the cost when a project is delayed due to inefficiencies in the development flow? The price tag of project set backs is best defined as the sum of both the incremental development costs plus the profits from missed revenue.
Consider expenses associated with projects that reach production ready status, only to find the revenue generation capabilities to be far less than the original plan. There is a huge prospect for savings here, considering the full development costs of a new product. The opportunity selection process must have visible financial metrics in place to monitor performance of this key gate to significant expenditures.
Resolution of project waste and inefficiencies can produce a fairly significant savings to an organization that invests in identifying and removing them. For those that ignore them, they still exist, quietly siphoning expenses with little fanfare or traceability. Diminish the impact of this big secret by identifying a visible price tag on project inefficiencies. This financial accent on project waste will provide the essential fuel to justify an emphasis on mitigating them and improving the overall efficiency of the organization.
Posted by Jeff Jorvig - IC Design Leader at 6:16 AM 0 comments
Thursday, July 09, 2009
Maximizing Activities that Matter to the Business
How would you define activities that matter? I am sure most of us have been involved in projects that did not produce intended revenue, and that is certainly a long list of activities that did not count. Activities that matter will produce the intended results, and in our world, the results must be profitable revenue. At the start of any project (improvement or product development) we generally build a case to convince ourselves that the projects activities will have a financial impact. Somewhere along the way the alignment to profitable revenue may fade, and in many cases this transformation goes unnoticed. Below are some concepts to guide you towards maximizing the activities that matter to your business.
Broad and Diverse Involvement
The only way to ensure your direction is sound is to make sure you have broad and diverse involvement. The shortest path to activities that will not matter is by way of a small team of like disciplined same-thinkers. Stir up the pot and involve those who will make things uncomfortable, the ones that are not members of the same-thinkers camp.
Commit to Continuous Alignment to Revenue
There is only one result that counts - revenue. If your proposed activities can't be successfully aligned to a financial business impact this should be a clear warning. Product development activities are generally always tied to revenue, whereas improvement activities are not. Any improvement activity must have a defined impact on revenue, as in a return on investment (ROI). Monitor the revenue assumptions on a regular basis. Are they still valid as the project progresses? Put a system in place to keep tabs on evolving assumptions and is prepared to kill a project that falls out of favor with revenue impact.
Understand the Past
Why did you put so much effort into activities that did not matter? Project history is extremely important and is the key to a better future. If results of a product development or improvement project were unsatisfactory, it is essential to understand why. Get to the root reasons and make changes in your process to mitigate these reasons for future activities. Failure to understand the past will guarantee a continuation of wasteful activities in the future.
Have a Clear and Engaged Sponsor
Any project needs someone to carry the flag high, keeping the team excited and focused on the benefits of a projects success - a project sponsor. The importance of this is even greater where the activities are related to an improvement project. Only engage sponsors that will ensure the continued reality of business benefits for the project and will be prepared to make a case to bail out if the advantages fade.
Application of these four concepts will definitely improve the impact of project activities, when honestly applied. These are not easy and will push you and your organization into uncomfortable territory - with results that will be noticed.
Posted by Jeff Jorvig - IC Design Leader at 5:18 AM 0 comments