Get Savvy about PLM

November 21, 2011

Consultaphobia

Filed under: Lessons Learned,Mythbusting,Organization — Laila Hirr @ 12:11 pm

I have observed some interesting dynamics around the use of consultants – what makes them valued, what makes them effective, reasons people avoid them.  Note that I DO make a distinction between Consultants and Contractors – Consultants should be bringing value, business level expertise, leadership, and a point of view and should be considered as a partner of the company engaging the Consultant.  Contractors are typically brought on for task level activities, specific technical solutions, to address gaps in capacity to complete a given level of effort (commonly thought of as Staff Augmentation).

1) Team member and Partner?? In this economy, when engaged on a project/program, having deliberate endorsement of the consultant is mandatory.  On this engagement – a contractor was frequently pointed to as a shining example of a success while the consultant not -  yet the consultant brought more to the table at a strategic level.  So why was the customer perception reversed – first of all the two were handled differently by the customer in terms of how they were introduced and engaged with the program stakeholders.  The contractor level resource was escorted by the director to every program meeting, introduced and given a vocal endorsement.  The consultant, interestly enough was viewed as a leader and therefore was let loose to go it on his own – having to forge a relationship path to every doorway.  Only after several months did the customer realize the impact this had on the consultant’s ability to drive for strategic results.

2) Not Invented Here – is the resistance to leveraging the knowledge of a consultant team related to NIH mentality or is it fear of revealing one’s laundry?  Both are motivations that are based upon the desire to prove one’s value at the cost of missing strategic opportunities.  One group was so focused upon doing it themselves that even when offered knowledgeable consulting support that would yield millions on ROI the team was adamant that they could not even spare the time to use the help (even though the help was funded).  Another team, realizing that they could leverage the help, made the same consulting team integral to their work.  The value of the consultant is only realized if engaged.

3) Can’t afford it – resource, time, or dollars.  Repeatedly I see organizations say this – and as a result they end up requiring years instead of months to gather the knowledge, the practices, and the expertise required to execute major strategic initiatives that can be easily documented as having tremendous ROI and business impact.  By proper identification of the business value, the benefits, etc – the cost of the consultants can be clearly offset by an accelerated path to delivery of the solution that is bringing value.

4) Disregarding the counsel given when it is unpopular – this one always surprises me.  Why pay for a consultant who has industry knowledge, expertise, and understanding of the myriad of complexities for the area of their specialization, and then minimize the importance of the issues they call out – whether risks, costs, recommendations, or opportunities.

If you are interested in further perspectives on the use of consultants, I recommend the book “Taking Advice: How Leaders Get Good Counsel and Use it Wisely” by Dan Ciampa

April 22, 2009

Successful Implementations – Invest in Phase 1 – Establish the Business Case for PLM

Filed under: Cost and Benefits,Lessons Learned,Mythbusting,Success or Failure: Lessons Learned — Laila Hirr @ 2:46 pm

A reader recently asked me to share perspectives on successful PLM deployments – what are the common themes across successful implementations.

The thought that comes to mind first and foremost is the upfront planning.  By planning I don’t mean the development of a project schedule or of the system requirements - it’s the investment in taking the time to really make sure the business justification is well understood.

There is a process I have used repeatedly that involves managing expectations very carefully before engaging the software vendor.  Too often it seems that the PLM decision is reactive – as sold by the software vendor, not based upon a clear set of business drivers.

To be successful with the process steps executive level endorsement is critical as it has a lot in common with a business process assessment in that it probes the entire organization, however, the assessment is focused upon the product record, not operations or production.  The challenge for many however having someone who knows  PLM well enough to be able to see the opportunities is often not a skill set contained within your company.  The cost of having consulting done for this stage is often well worth the initial investment when taking into account the overall investment you may end up making in the implementation.

The single most significant thing to be done is to look at the PLM project with the same kind of rigor as a product development project.  Too often IT projects (coming from a non revenue perspective) fail to use simple PMO types of processes.  It all starts with the business case phase.

phasedprojectplans

But on the successful implementations – the business case stage would include the following activities:

  1. Take your organization chart and mark every department that handles product related information, identify key external partners that are also interacting with your product records (note – do not count your financial transactions here – just focus on the product information).
  2. Evaluate each department around it’s  handling of product information or the product record look for manual transactions, duplicated entries, printouts, markups, shadow databases, network storage of product information.  Include examining what IT infrastructure components are involved.
  3. Dollarize the impact of the “non-value” added activities associated with these product record related transactions – the caution is that executives will readily let you turn this into a blame game rather than a financial business case – so be careful how this is framed (Read the Dollarization Discipline for more on this).
  4. As in product development project management practices – develop a high level specification (similar to a Market Requirements Document) that ties business objectives to the functionality requirements – this is NOT where to say it must run on xyz database, or have n tier architecture.  This is a market level specification for executive consumption.
  5. Obtain executive buy-in for the next stage – do not go too deep into specification definition until this phase is approved.

December 18, 2006

Failed PLM Deployments – Part 3

Filed under: Lessons Learned,Success or Failure: Lessons Learned — Laila Hirr @ 12:25 pm

Danger #3 – Stopping at end of Phase 1

Time and time again I see the same thing happen on deployments.  The beauty of PLM is that the benefits begin almost as soon as the initial installation and configuration is done (many midsized companies can have a live system in 1-3 months) unlike ERP deployments which at best will take 6 months and often over a year to implement.  The danger of PLM is that when the initial system is deployed the project is “stopped” because it’s implemented – but the true power has not even yet been touched.  Here are some real cases I’ve encountered:

Company A:

Using Agile 6.5 the company had determined that they needed to upgrade to Agile 9.X in order to extend change management to their outsourced partners.  The analysis of the business benefit showed that the straight upgrade would only meet 50% of their system requirements and that by leveraging the newer features (which required continued process changes and configuration changes) they could obtain over 95% of their business system requirements with the newer release.  The project was laid out in 4 phases in order to manage the business impact on the company as a whole rather than try a big bang approach.  Phase 2 would meet another 30% of the requirements, Phase 3 would meet about another 15% and a final 10% of the requirements would be met by Phase 4.  Each phase was shorter in project demands and lower in cost – and the original executive approval was based upon these findings, but each phase was to be funded as each phase was started.  But as feared – phase 1 was completed and the “urgency” of the remaining 45% of the business benefits was lost – the momentum dried up and the remaining phases were not pursued.  Overall the users had a perception that the tool never met their expectations as it was never fully deployed.

Company B:

This company deployed MatrixOne as an engineering department change management tool yet did not pursue leveraging it as a enterprise product information management system.  As a result when discussing product change management with the manufacturing organization, the perception was that they had only manual change processes because the tool was not extended across the enterprise but was only deployed as a departmental solution.  Engineering would toss a bill of materials to production and it would no longer be managed within the enterprise level vault that the company owned.

Copyright 2006, LR Hirr, All Rights Reserved

November 2, 2006

Failed PLM Deployments – Part 1

Filed under: Lessons Learned — Laila Hirr @ 10:06 pm

The unfortunate reality is that some deployments fail, and they predictably fail.  I will share some case studies of deployments we’ve seen fail and the top reasons why.

Danger #1 –  Bypassing the Discovery/Feasibility Phase

At Company A we were contracted to assist with the requirements gathering and initial qualification list of PLM suppliers.  The company was bracing for major outsourcing, trying to address RoHS issues, and living with an older PDM system that was sorely in need of updating.  They had extensive workarounds to having limited workflows and had a strong need to leverage product change management with their supply chain.  They had a clear and sound business case for investing in the next generation of PLM systems and wanted to do their due diligence in assessing candidate applications.  They contracted with us to conduct the Discovery phase of their PLM initiative.  We met with stakeholders from each department, gathering requirements and developing a prioritized list of feature/functions that they would need and the business benefits to be gained from each level of capability and based upon that list began culling the list of 7 PLM providers down to a target list of three who would then have to provide a full capability evaluation to be considered as potential solutions.  This was all consistant with Company A’s IT project management directives. 

The problem arose when the internal program manager decided he needed an exit strategy – he was preparing to leave the company and did not want to leave an “open” ended status on the selection process.  Upon learning that 2 of the 7 PLM solutions had been disqualified based upon early assessment of the capabilities compared to requirements – he convinced his management that a straight upgrade of the existing PDM system was the best path and halted the discovery process and procured approvals to move forward with the upgrade, and then he left.

The problem was multifold -

  1. The end users had the perception, due to the information gathering that had taken place, that the upgrade was a “qualified” selection.
  2. The upgrade would not have passed the qualification process based upon the requirements to demonstrate functionality – but the vendor never had to show they could do what they said they could do.
  3. The vendor would not have passed the due diligence process in that it could not provide any referenceable customers for the solutions they were offering.

In the end the deployment was considered a corporate wide failure due to lack of user acceptance and due to the “bugginess” of the upgraded offering.

At Company B we were contracted to assess the feasibility of using their existing ERP system which boasted workflows and document management as a change control tool.  We evaluated the business processes and regulations that the company had to adhere to along with accepted change management processes.  We also delved into the actual functionality of the ERP system’s solution by building a sandbox to test various concepts considered to be core to change management workflows.  This took several weeks – by which time the Director of Engineering began pressing for the “ECO” design that would be implemented with the system.  We paused and pushed back – reminding him that we were still in the feasibility phase and that any process design would be premature if developed without understanding what the tool could or could not do.  He agreed to wait, very wisely too.  Less than a week later it was evident to every member of the company team assigned to champion the effort that the ERP system would fail as a long term solution for change management and a new path was quickly taken with full executive management support.

In the second case – dispite the eagerness for a rapid solution, waiting and commiting to the feasibility process saved this company years of potential struggles. 

Copyright 2006, LR Hirr, All Rights Reserved

Theme: Rubric. Blog at WordPress.com

Follow

Get every new post delivered to your Inbox.