Here’s something new in this blog – a post I’ve mostly not written. Below is a response from Russell Forsyth on the subject of the how to get that “time to value” in an implementation which I addressed last time. He’s a Senior Consultant with Mentor Consulting Division Americas. We’ll try and keep this under 20,000 words by not going through Russ’ successes and accolades.
Russ has the view competent of teams and individuals base their success on the discipline of a project management methodology to keep implementations of Capital locked on to their business targets.
Feel free to make you own opinions known via the comments on this important subject.
Russell Forsyth writes …
“Following on from Paul’s enlightening post previously on the deployment of the Capital tool suite, I’ve been invited to elaborate further on how we in Mentor Graphics Consulting tackle a Capital deployment.
Getting the right people involved, correct planning, executive sponsorship and guidance are the key tenets; and they form the cornerstones of the “P3roven-led” deployment methodology that we use to get you from your current position, to full-scale production with the Capital tool suite.
Structure your implementation.
So what does deployment actually mean and why is it important to get right? In essence, structured deployment is all about moving you as an organization from your current design flow to production usage of the Capital tool suite in the most efficient manner. A graph I usually use to illustrate this concept is shown below; as with any change there will be pain – changing tools and design processes is non-trivial and needs careful consideration and planning.
The graph starts by showing your current tools/processes – the main point being that over much time, your productivity will increase (however bad your tools and processes are) as everyone learns to deal with the obstacles and fill in the gaps where required.
The motivation for change is normally driven by some compelling event; perhaps your current tools/processes are based on outdated hardware, are dependent on the gray-haired guy in the corner who’s about to retire or maybe the tools are just running out of capacity with your ever-growing design sizes and complexity.
Whatever the motivation, the dream is that you’re going to make an investment in new tools and see a step-improvement from day one
The reality is somewhat different – unless the deployment is managed properly, your user base will be plunged into a state of confusion – not aware of their revitalized role with the design flow, possibly inadequately trained and perhaps those integrations that you had with your previous design tools got somehow overlooked with the new implementation.
In order to reduce that drop in productivity (the area under the curve) you need planned, structured tool deployment.
As I mentioned earlier, the methodology we use for the deployment of the Capital tools is known as P3roven. Fundamentally this breaks the somewhat large perhaps overwhelming task of deploying new tools/processes into several smaller projects as illustrated below.
What starts to become clear is that introducing new tools/processes into your production environment presents a risk to your ongoing delivery commitments. Being able to split the deployment into a guided Pilot followed by an Implementation project significantly lessens this risk and allows off-cycle iteration before ‘going live’.
By now you may have noticed there is some neat color-coding going on and this is no accident – the P3roven name denotes the 3 “P”s of success; Planning, Preparation and Performing. This idea applies to each project within the overall deployment.
Planning – Purple
For example if we consider first the guided Pilot, the first task is one of planning – an activity we refer to as the Process Evaluation. This typically consists of our Consulting experts spending time with your SMEs to review the current design flow, requirements of both design and greater business organizations and overlaying these onto the capabilities of the Capital tools. This allows us to propose a “to-be” design flow and plan for the subsequent Pilot project.
Preparation - Blue
After Planning comes Preparation – the tuning of the Capital design environment to satisfy the requirements captured during the Planning phase. This will include the implementation of user management, change management and corporate Intellectual Property (such as drafting standards, design rule checks and constraints) into the Capital design environment as well as enablement training of your ‘superusers’.
Performing – Green
The final stage is the actual delivery of the Pilot project itself – this is where representative data is pushed through the Capital environment to check for any ‘wrinkles’ that need addressing before the production roll-out. What we typically see here is that there may be areas of improvement that can be made ahead of the roll-out – such as the inclusion of an extra DRC here, a custom report there, anything that will improve the efficiency of the final Capital tool setup.
Best way to peace of mind and showing great benefit.
The choice of the representative data to be used during the Pilot is critical – it should be of sufficient size and complexity to really test both infrastructure and design flow. It’s also a great idea if the target dataset is one that has already been ‘designed’. That way you know how long it took to develop in your old design environment and also what problems caused downstream ECR/ECNs to be raised.
What better ROI to present to your upper management than that with the new tools, the same design was both quicker to capture but more importantly avoided ‘x’ number of design issues!
Once the Pilot project is complete there is a feedback path to the Planning stage for Production. Typically this is smaller than the Pilot as it is a refinement based on the lessons learned.
Upon the conclusion of the Planning stage it’s into the Preparation phase and subsequently into Performing.
So that was a brief overview of the methodology we use – it’s something that we do day-in day-out and have the expertise to assist you with. This knowledge has been built-up over many customer deployments – what is interesting, is that over that time, we’ve been able to categorize indicators of success and failure; which brings us all the way back to Paul’s initial post…
Once you have a plan and agree to conduct a Pilot project, you need the right people – as Paul points out, you certainly need executive sponsorship in order to make anything happen. Once that’s in place it comes down to having the right people in the mix at ground-level, individuals that have both domain and tool knowledge to make it a success.
If you’d like further discussion on this, feel free to contact either myself (Russ Forsyth) or Scott Majdecki a note: firstname.lastname@example.org in the U.S. or email@example.com for the rest of the world. Thanks for reading. “