In my previous article we discussed the often overlooked need and value of process mapping prior to implementing Product Lifecycle Management software. If Batman is considered somewhat of a lesser superhero what does that make Robin? Being a sidekick is never good. You end up doing a lot of the dirty work while the superhero gets all the credit. Project Man suffers this fate. From a PLM implementation perspective project management is often overlooked or minimized but a well-defined and monitored plan is really the only way to be successful. Those lengthy enterprise software implementation projects almost always suffer from a lack of planning and oversight and this is where Project Man shines. After Process Man has come in and built out the shiny vision someone has to figure out how to make it happen. This blog will talk about the best methods for managing PLM projects and the perils of being a superhero without a sidekick.
The first question to ask is why does Batman even need Robin? The recent Batman Begins and Dark Knight movies portray Batman as a loner. Even Alfred doesn't seem to have much of a relationship with him. While the two movies make for compelling cinema I think we can see where things are going. Without structure in his life and some contact with other people Batman's life is spiraling out of control. He needs Robin to pull him back to normalcy to have someone to care about and to remind him of his true purpose. There are several blogs that do a more articulate job of explaining the dynamic between Batman and Robin but I do think there is a similarity to the relationship between Process Man and Project Man. The Process Man blog garnered a lot of feedback and in one of the comments from Doug Halliday he talks about how process can be over-defined and complex. I think he makes a good point about how PLM implementation is addressed and I think really thinking through how you are going to execute a plan can address this concern. Moreover, I believe there is a backlash against complex and ambitious projects because of poor planning which results in ad hoc or very little project planning for PLM implementation which can be even more harmful than the overly complex projects Doug writes about. There is a balance between the two extremes and when Process Man and Project Man work together the results are optimal.
Hopefully, you are convinced that there is merit to project management in PLM implementations but what are the tools of the trade? How does Project Man rein in the unruly mishmash of resources and tasks that usually constitute a PLM project and make sure that Process Man's vision is achieved? Obviously, the first thing to do is to create a plan. In our industry that usually means a Microsoft Project Plan or an Excel spreadsheet. There are numerous mediums but the general format is a list of tasks, resources and timelines organized in some manner. Once this overall mapping exercise is accomplished you must get granular. Breaking things down to a task level and making sure everyone has a clear understanding of their role in the project is critical. This includes both the vendor and the client. Many times project plans get created in a vacuum and once they see the light of day they disintegrate into the air. Working up front with the client to understand their windows of availability and the critical milestones is a must and can make a huge difference in whether or not a project is successful. In most situations PLM software is being deployed into an active organization that has obligations and deadlines and is probably already operating at maximum capacity. Project Man must account for this in his plan or it will never work.
Once the plan has been created and the project is under way the real fun begins. I think we are all familiar with the Yiddish saying "Man plans and God laughs" or the more contemporary Woody Allen quote "If you want to make God laugh tell him about your plans". The gist of all this is to make sure your plan is written in pencil because it will change. This is where Project Man really earns his keep. Staying on top of a project and making sure things happen in a timely and accurate manner is probably more challenging than creating the plan itself. There are numerous things that can happen along the way that will impact the time and tasks involved in PLM. Sometimes events occur that require modifications to process or architecture. People get sick, leave positions, make mistakes etc. It is an inexact science at best and being able to account for this is one of Project Man's key strengths. He is relentless in his pursuit of the project and communicates effectively with all parties so they understand the impact their actions have on the project. The takeaway from this is that Project Man is no shrinking violet. He must be aggressive yet diplomatic in his attempt to corral all people and information needed for successful execution of the project.
Project Man is an afterthought after an afterthought. This can be a critical error if you are embarking on any type of process improvement activity. You must allow for robust project management if you want to have a chance at success. Marrying vision with discipline is the optimal approach for deploying strategic solutions like PLM. The marriage of purpose and goals with the pragmatism of execution keeps things from being too ambitious and ensures that the project will be completed in a reasonable amount of time. Following up with vigorous oversight ensures that the project stays on mission and that the initial objectives are achieved. Even small "out of the box" PLM implementations need this dynamic duo. So don't sleep on Robin or Project Man. Without them there is no balance and things go awry. Even having the power of Superman/Application Man is wasted without vision and planning. Tune in next Tuesday to see the characteristics and the value of Application Man.
[Edit: Repost from 2012]
Check out our implementation presentation!
