Eager project managers – and new project managers – may like to just jump in head first into a new project and show enthusiasm and prove to their senior management that they are go-getters. That’s nice, but it may also be stupid. Or these overly eager PMs may be sending the wrong message to their leadership who is 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, make sure both feet are firmly planted on the ground, and you are ready to serve the customer appropriately is to go into the engagement knowing a few things first.
This all comes to mind mainly because – amazingly – I was handed a project and 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 project manager on the customer side. 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 very 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 on. Without proper documentation such as a statement of work or previous notes, status reports, etc. when taking over… he is heading blind into any discussion he is 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 – yes, before – starting a project or taking over a project… before engaging the project 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 to his idea so he could refine his idea for the 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? That can help us – because it can help us figure out a few things like what not to do, or possibly some added insight into current business processes, or maybe make the project more affordable by proposing an add-on to cover the needed functionality rather than completely rebuilding the system. There are always options – you 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/pricing for the project, then whether or not loading legacy data into the system and how data will be integrated into a new solution are two critical pieces of information. They 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 from the project? Finally, when is this project needed? You may start out putting together a plan to propose to the project sponsor based on what you have been given and you’re about to propose a 14-month project schedule. It would be very helpful to know from the project sponsor that they MUST have the solution within 6 months. Knowing that before you put the effort into the schedule allows you to either somehow plan to meet that incredibly tight timeframe or to plan a phased implementation and begin planning negotiation points on why your approach will work for them.
Summary
Heading into the unknown is tough going. We can waste a lot of time and look like fools in the process trying to plan for and prepare for a project engagement that we know little about. The key is to get as much information together – up front – as possible. And 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?
The best way to start the project properly, make sure both feet are firmly planted on the ground, and you are ready to serve the customer appropriately is to go into the engagement knowing a few things first.
This all comes to mind mainly because – amazingly – I was handed a project and 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 project manager on the customer side. 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 very 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 on. Without proper documentation such as a statement of work or previous notes, status reports, etc. when taking over… he is heading blind into any discussion he is 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 – yes, before – starting a project or taking over a project… before engaging the project 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 to his idea so he could refine his idea for the 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? That can help us – because it can help us figure out a few things like what not to do, or possibly some added insight into current business processes, or maybe make the project more affordable by proposing an add-on to cover the needed functionality rather than completely rebuilding the system. There are always options – you 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/pricing for the project, then whether or not loading legacy data into the system and how data will be integrated into a new solution are two critical pieces of information. They 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 from the project? Finally, when is this project needed? You may start out putting together a plan to propose to the project sponsor based on what you have been given and you’re about to propose a 14-month project schedule. It would be very helpful to know from the project sponsor that they MUST have the solution within 6 months. Knowing that before you put the effort into the schedule allows you to either somehow plan to meet that incredibly tight timeframe or to plan a phased implementation and begin planning negotiation points on why your approach will work for them.
Summary
Heading into the unknown is tough going. We can waste a lot of time and look like fools in the process trying to plan for and prepare for a project engagement that we know little about. The key is to get as much information together – up front – as possible. And 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?
RSS Feed
