Working on a project has made me think about a method to ensure success. It is so obvious, it should not need to be documented. Yet here I am. What are the three functional elements of every project?
Those three elements surrounds the only reason why you have a project to begin with: requirements. Envision a triangle with each element taking a corner and the requirements in the center. You obviously would like a equilateral triangle, meaning all three elements are equal to ensure the project is met on time, on budget with the resources available. The reality is that you try to move only one of the elements to ensure the other two remain static (more time, more resources or more money). So the real question here is not when you have to move the elements around but why.
There are many reasons why elements of a project move, unforscene technical challenges, changes to resources, or budget management just to name a few. But what keeps most PMs up at night is the one thing that should not change and is one thing we do not have any control over, the requirements of the project. Scope creep, or extending requirements, happens all the time. We fend them off with great use of PR language to help defend the three project elements given. What becomes a problem is when scope creep reveals requirements that are not fully thought out with the project already in the execution phase. Pushing a solution and evolving the process of how to use that solution should never happen concurrently. This is where project pre-planning is so critical, more so than the project development itself. The project kick-off meeting is the key. Before calling this meeting, make sure you do the following:
- Audit each requirement to ensure it is bound to an associated and accepted business process
- Define the major players and invite them (they are always different than the customer requesting the project)
- Bring in the GUNS!
Audit the Requirements:
What kills every project is process, seriously! People have an idea on how it should work, they hash it out with a couple of people to apply a reason why it is needed and then it is handed over to the developers to make it happen. Stop the project immediately if you ever hear, “hmm, never thought about that…” Every requirement handed to you should be accompanied by an accepted, meaning management approved business process. NOT a business definition of why it is needed. Why do they need to convince you? That is a conversation between the customer and management. Your job is to make sure it can be done in a realistic manner.
Any requirements that is open-ended and represent a “new” feature, should be tagged for discussion. If you have someone that manages all the processes in your area, this will be easy. If not, then be prepared to put on your best PR hat as you will need to push back to the customer the tagged requirements that are not clearly defined.
The Major Players:
This is always fun. A customer that has done their homework, will provide you with such exacting requirements that the kick-off meeting is a simple walk-thru of how the solution will be used by the departments and how to execute the finished product. Red flags should go up when a discussion that does not delve deeply into the requirements shifts over to why this will be great and wonderful. Once again you should never be in a position to be convinced why. The conversation should always be on execution.
To ensure project requirements are as complete as possible, bring in the players of the departments affected. This should have been set up for you by the person requesting this work, but if not, then just do it. Preface the meeting with the desire to “be on the same page.” This is your time to get out and meet the folks for a quick chat, “Hey Bob, I got this project on my desk that affects your area, is it cool if I invite you to my kick-off meeting? I just want to be sure everyone gets the same message. Thanks.” DO NOT leave your customer out of the loop. Oh boy, you really never want to create a situation where it seems you are going behind that person’s back. Give the person a heads up if it is cool to bring others into the kick-off meeting. You should obviously do that before you talk to anyone. If for some reason they say no, use PR again and let them know that you really want this project to succeed and to do that we will need everyone ‘on’-board and ‘on’-message.
Bring the GUNS:
You got the tagged requirements, you got everyone you need and you walk into your meeting with all eyes on you. Use the guns that got you here, PR, PR, and oh yeah PR. Be prepared to push now and hard. Get the folks use to the fact that you are there NOT to stop the project or to be convinced, but there as the practical appliance with the desire to seek success. Use this time to bind processes, review processes, link processes and heaven forbid create processes. If a process cannot be defined and has to be created, kick it back and call another meeting. Hey, do that now and get people working. It is either that or sit in a meeting a few months down the road trying to explain to others why they were not tasked appropriately. Always remember, it is never their fault when something goes wrong. Like a good psychologist, you do not find solutions, rather you lead others to discover how to solve it themselves.
Are you noticing a theme here? Project Management is all about conversation. A great PM does not need to know how to do any one person’s job. They just need to be an effective traffic light. The hardest part of the job is the requirements, because that is one element you do not have control of. What you do have is your ability to make sure when the requirements that are presented to you, are in a form that you do not have to worry about during execution. That is where all this planning comes from. Let size dictate the length of pre-planning. The larger the project, the longer the pre-planning. Execution should be mindless and automated. Life is good when that happens.
Hey everything stated above should be obvious, but let me tell you from experience, it does not take much to get involved with a project where these things do not occur. You then spend all your time fixing things that should not be your responsibility. This happens to the best of us, me included.