5 Things to Know Before You Start the Project
Eager project managers – and new project managers – may like to jump in head first into a new project and show enthusiasm to prove to their senior management that they are go-getters. That’s nice, but it may also be stupid. These overly eager PMs may be sending the wrong message to their leadership, who are really looking to see if they show any knowledge at all about how they should go cautiously into the night on a project… not jump in with pistols blazing.
The best way to start the project properly is to go into the engagement knowing a few things first. Make sure both feet are firmly planted on the ground, and you are ready to serve the customer appropriately.
This all comes to mind mainly because – amazingly – I was handed a project where nothing was known. Seriously… nothing. We had a developer working on the project already. He was doing some preliminary work on an interface for the project working with a customer-side project manager. Other than the generic interface we were tasked to do, we knew nothing about the project. Nothing. And I was about to jump on a call with the sponsor on the customer side. I had nothing to go on – no documents, no status reports (everything had been verbal sprint meetings to this point), and no statement of work (SOW). Nothing. Ummm…ok. Actually really it was not ok.
So, here’s my list of a 5 key things I like to know going into a project:
What exactly is expected of the PM and team? It is imperative that the project manager knows what the team should be delivering. Without proper documentation such as a statement of work, previous notes, or status reports, a project manager is blind heading into any discussion they are having with the project sponsor and customer team. It’s a no win situation – no ability to plan, no ability to ask or answer questions intelligently. Before starting a project or taking over a project, even before engaging the client, the project manager needs an idea at least of what the project involves.
Is funding in place? Is there money for this effort? This tells you how serious the project customer is. Are they looking for free advice or are they really planning to engage your services? I had a potential consulting client who I suspected was just looking for me to propose something so he could refine his idea for a project. He basically wanted a free strategy proposal. I created a proposal – a good one and it was detailed – but I also required that it be a paid deliverable. He was surprised, but he paid for it. I knew it was the only money I was going to get from him because he was just fishing and I couldn’t afford to give my time away for free.
Does a legacy system exist? Are we building something new or is there a legacy system in place that currently does this work? Knowing this can help project managers figure out a few things like what not to do, or possibly give some added insight into current business processes. This knowledge may make the project more affordable for the client by being able to propose an add-on to the existing functionality to cover the needed feature rather than completely rebuild the system. There are always options – PMs just need the full picture in order to propose those options.
What data integrations will be necessary? If you are still working through the financials and pricing for the project, then whether or not loading legacy data into the system and how this data will be integrated are two critical pieces of information. It may seem trivial, but data can be very complex. Loading old data may mean data needs to be cleansed – basically cleaned up and reformatted to fit into a new solution. And as far as integrating it into a new solution – tying it into the data fields and getting the new functionality to talk to the existing data the way it needs to can be very difficult. This is key information that is needed for requirements definition and pricing.
What is the timeframe for the project? Finally, when is this project needed? You may start out putting together a plan based on what you have been given to and are about to propose a 14-month timeline to the project sponsor. It would be very helpful to know from the project sponsor that they MUST have the solution within 6 months. Knowing the timeline before you put the effort into the schedule allows you to either plan to meet that incredibly tight timeframe or plan a phased implementation. You will need to begin planning negotiation points on why your approach will work for them.
Heading into the unknown is tough. Project managers can waste a lot of time and look like fools in the process if they try to plan for and prepare a project engagement that they know little about. The key is to get as much information as possible up front. Knowing the right information is critical to planning properly, making good estimating and team building preparations, high-level requirements definition, and knowing how to prepare for and execute any project kickoff activities. Going into a project engagement or any discussion with the potential project sponsor completely blind is dangerous and can lead to a project not getting off on the right foot.
What’s your take on this? When have you had to take on a project with nothing to go on? What did you do? If you were a consultant, did you skip that project? Did you dig further? Did you head into meetings with no clue hoping to gather some helpful information? What other key info – especially on tech projects – other than what I’ve listed above, do you usually need to know before getting started or even meeting with the client?
Don’t forget to leave your comments below.