Project Governance and Definition
Walking onto any troubled project, guess what I hear? We are spending too much money, we cannot miss the due date, we need everything we are asking for, and it is "their" fault. My job is telling them the bad news—we need more money, we are cutting scope, and the project is still going to be late. Those are the unavoidable facts and the stakeholders need to accept them. Worse than that, I am not going to blame anyone. Blame is counterproductive. So, how does this compare to the situation with the United States Congress? In short, they do not get it. They need an apolitical, outside entity to build the recovery plan—just like we do anytime we are recovering any project.
New plans require change. Change is difficult. Employees, contractors, vendors, and even customers need to change how they work to adapt to your new plans. What is in it for them? Attempting to implement new plans without reinforcing the goals, reasons, and benefits to each stakeholder will result in people reverting back to their old ways. To help people assimilate change and truly move forward, we provide a series of seminars and workshops that address improving change adoption. Our unique Visualizing Change workshops not only help you understand the problems at hand, but also teach you effective techniques for addressing the motivations of all parties involved, so that you will successfully implement lasting change.
Change is difficult. Regardless of who you are, it is tough. Recently, I challenged readers of this blog to improve how they tie their shoes. I can confidently wager that a large majority have stayed with their old habits. It takes significant force to reprogram out brains, affect the cultural inertia, and gain acceptance to change, tolerance of occasional mistakes, and, eventually, achieve an organization steeped in transformational principles. Nowhere is it more apparent than when delivering projects that alter the way people perform daily tasks. The reason is that, all too often, the goal is to deliver the project; it is someone else's job to gain adoption.
Why would anyone need to teach a group of managers how to tie their shoes? It seems improbable anyone could make it to this point in his or her career lacking this simple skill. However, I feel quite confident that a vast majority of project managers, managers, leaders, and probably you, are improperly lashing your laces. This prognostication will go one step further stating that even after proving a better method, they, and you, will be unwilling to put forth the effort to change. Adopting change, beyond just tying your shoes, is at the root of our inability to improve many of our business processes. Furthermore, studying this behavior and the subsequent difficulty of maintaining a new and better method will help us understand the high recidivism rate.
The other day, someone said, once again, that an issue we were discussing was like pushing string. She said it with the sigh of resignation in her voice. I understand the metaphor, but the people saying it are stuck looking at the problem wrong. Immediately, two solutions to their dilemma come to mind. First, add a little water, freeze the string. Voilà! Push that string wherever your little heart desires. If that is too hard, then roll it into a ball or put it on a spindle. Now, we can push, roll, carry, and even throw it. The problem is the predisposition to the inevitability of the issue—there is no reason to look for a solution because it is out of our control. Worse than that, we are so defeated that we rarely ask the question "Why are we trying to push that string?"
A project manager's job is to deliver value. Achieving the original schedule, budget, and features is meaningless if the customer does not receive value. As with all simple statements, this much easier said than accomplished. Projects managers must assemble adaptable teams that use flexible, lean methodologies. Arrogantly selling the latest technology or tool is narcissistic. Focus on the customer. Be vigilant at ensuring the information is always available for the customer to reassess the project's value and for the project team to reevaluate their proposal.
"People say I am indecisive, but I am not so sure about that." I have seen this quote attributed to a former US President, but I doubt he actually siad this. First, it is too intelligent a comment for him and, second, he is far from indecisive. The liberal pundits trying to attribute that quote to him confuse indecision with defective decision making. You can figure out who the President is on your own; however, it is irrelevant. This article is about leadership not politics. Organizations confronted with a decision-challenged individual in a leadership role, is adrift in the sea of serendipity. They bobble around having no direction.
The system integrator is the magical troupe that works with the customer and the software vendor to deliver a project's desired functionality. They cut through the vendor's promises while controlling the customer's expectations to create a successful deployment. Mike Krigsman refers to this triad as the Devil's Triangle; all three parties are culpable in the failure and share in the success. However, the system integrator is responsible for holding the three together to achieve successful delivery. The cornerstone to this relationship is a thoughtfully built contract.
I have always enjoyed being part of team building exercises. The one where you close your eyes and fall backwards hoping that your team members catch you is my favorite. It reminds me of an amusement park ride. There is always the thought in the back of my mind that some trickster will let my head crack on the floor. I think it adds more excitement. However, team building exercises only go so far and normally fail to reach their objective. They are too transient. The event happens, the manager checks off the list to show the task is done and he or she goes back to managing the team with status reports, task assignments by email and visiting people only when something goes wrong.
People, who know me, are aware I am less than enamored of certifications and titles. Therefore, when I got my PMP many were taken aback, some laughed aloud, and, since I seemed to get it overnight, all asked why and how I got it. However, it is not just my situation, this is a perennial question in online forums and groups and it is a common topic at local project management meetings. In many of those discussions, people try to analogize the PMP to a CPA or MBA; without question, the requirements to get a PMP have none of the independent educational rigor of college level degrees. The PMP's worth is visceral and personal—it depends on each individual's goals and their project management experience.