If you are following along this is the third article in this series. After Stephen Covey's untimely departure from this world I decided as a tribute to him to break down the 7 Habits of Highly Effective people and apply them to product lifecycle management (PLM). The first habit was"be proactive" and we looked at how "quick fix" solutions can limit the effectiveness of PLM. The second habit was "begin with the end in mind" which in PLM speak means develop your outcomes and work backwards from there. I think the title of Stephen Covey's third habit is a bit misleading. At first glance it would seem to be about prioritization when it is really more about time management and having the discipline to manage well in general. In this third entry in the series we will review the importance of PLM project management and how effective project management is a key contributor as to whether PLM adoption succeeds or fails.
Early in the chapter Covey states," Effective Management is putting first things first. While leadership decides what first things are, it is management that puts these first, day by day, moment by moment. Management is discipline, carrying it out." If you have ever been involved in an implementation of PLM you can relate to this quote. Most of the time it is not a question of knowing what to do it is having the discipline to actually do it. In the context of PLM it is developing a plan and then sticking to the plan. Why is it that this is so difficult? Covey quotes an essay titled "The Common Denominator of Success" by E.M. Gray to better understand this challenge, "The successful person has the habit of doing the things failures don't like to do," he continues, "They (the successful person) don't like doing them either necessarily. But their disliking is subordinated to the strength of purpose." Hopefully, if we follow habit two we have that purpose to follow and then it is a matter of making sure the activities we are managing lead us to that outcome.
Another interesting point Covey discusses in this chapter is delegation. Typically, in a PLM implementation setting the external consultants will drive the project for the most part. In the interest of efficiency they tend to blast through things fairly quickly so that they can move on to the next project. Unfortunately, the end result is that the company itself has a lack of ownership and knowledge that can severely hinder the effectiveness of the PLM initiative. Some companies organize strong internal groups to drive the project to account for this but even in these situations their lack of knowledge or experience can make them more of a hindrance than a help. Covey talks about transferring skill and knowledge as a way to energize other high level activities. It does take more time up front but in the long term it is time well spent. He talks about several areas for what he calls "Stewardship delegation". In the next few paragraphs we will review these areas.
"Desired Results" is the first area. Covey emphasizes that there needs to be a mutual understanding on "what, not how; results, not methods." This is why discovery and needs assessment are a critical step not just for the service provider but for the client themselves. Many times companies do not understand their own issues as well as they should. This harkens back to the previous article about starting with the end in mind. Don't move on from here until everyone is on the same page. Related to this is the next area, "guidelines". The key is to stay as open about how things are done as possible and focus on the results. When you delegate if you are overly restrictive you have defeated the purpose of delegating. If you spell out every little detail you might as well do it yourself. By defining the outcome but not the method you give someone the opportunity to think critically and become more engaged. So in the context of PLM you might task the client to provide requirements for certain workflows or data mappings but leave it open ended as to how they are structured. Finally, in this grouping he includes resources as the final area. Obviously if the client is not an expert they are going to need access to people and systems that will support their tasks. Helping them understand where they can go to get the information they need is far more helpful than just giving them the data. This will allow them to be more self-sufficient in the future.
The last two areas are somewhat related, "Accountability" and "Consequences". Delegating without these two things in place can be dangerous. People need to know they are "on the hook" and that there are expectations associated with their performance. If delegated tasks are not performed then it can impact both the timeliness and quality of a project. If someone has been tasked to create test scripts and the test scripts are inadequate then the quality of the deployment could be impacted. Incomplete requirements can lead to a system that does not fully support needed use cases. Companies need to buy in up front that their participation is a critical element in the success or failure of the project and personnel need to consider their activities as a priority.
This chapter and habit really emphasize the importance of management in any activity and how delegation can be an effective way to be more successful and produce better results. With PLM projects the temptation is to blast through the activities and get the project done but considering the fact that companies need their people to fully understand the system delegating parts of the project to them is the best way for them to better understand the new system. Companies should insist that their people play a large role in the PLM implementation activity and vendors should design their methodologies to encourage this. It may take longer but it ensures better long-term value for the client and for consultants and PLM vendors this should be the "first thing"
[Edit: Repost from 2012]
