|Posted by Global Learning Labs on October 2, 2015 at 1:10 PM||comments (0)|
It is true, Project is to deliver as per the Statement of Work and meet all the implicit (like high quality) and explicit (like (Non-functional requirements) requirements.
SOW – Statement of Work, ideally, should equip PM with all the things expected by the customer. But it rarely happens. SOWs are typically just a construct for the commercials and high level milestones or stakeholder information.
Best practice is to ensure that all this information is pre-agreed with the client so that the PO (Purchase order) generation inside the client systems is done quicker.
Ok, so your SOW is done, PO is obtained.
So, what now? start coding?.
As a project manager, you are expected to do a lot of pre-planning on how the project has to run.
At a bare minimum, you have to be very clear on what the customer as well as the company that is paying your salary expects from you and your project. Plus, you have or will have your team members who have probably 180 degree opposite expectations from the project.
So, let us look at the customer first.
The one obvious thing is that the customer wants the project delivered as per the requirements. Yes.
Now, while we all expect you to know everything and be everything, it is just not feasible. We all have our strengths and skills that we bring to the team.
But, you do need to know the requirements to quite an extent. You will have your Business Analysts who will work with the client BAs to detail out the details. But, you, as PM, need to know what you are going to deliver against.
While these requirements are getting nailed down, you need to ensure that your tech lead or your architect or your senior tech analyst or you (if no one else is there) request the client to put together the NFRs.
A best practice at this stage is also to figure out what are the goals of the key stakeholder you work with on the customer side. That becomes your initial set of implicit requirements.
Next is to figure out how often and in what format your customer expects to get more information on the project. That becomes your communication plan.
Have you ever stepped back to really see the program from the client’s view. Let us take the case of a program that is critical due to legal nature of it or because of a key audit dependency. If the project does not succeed and closes, you will probably move on to another project. But your client might be the person who actually loses his job!
Have you done proper due diligence on the information you send out? Do you send complete and accurate information that also addresses things that are at least 1 step ahead? Do you raise the right issues at the right volume at the right time? If you really do all this, your client will be your biggest supporter and fan. For life.
Well, having addressed your thoughts, let us come back.
During the SOW finalization, you would have done a high level estimation of effort, team size requirement and key date finalization. Now, you need to break that down and create a detailed project plan.
Before coming up with the plan, figure out the risk mitigation plan first. Next, figure out how good your team really is. Do not go by designations. Go purely by skill and talent in not only managing the technology but also the associated process and the people. These two inputs will go a long way in cementing together a rock solid project plan.
At this stage of creating the project plan, you know the requirements, you know your people, you know the customer’s implicit needs, you know the communication plan, you know the final and intermediate deliverables and you know all the major risks to your project’s success. Build a slack in your plan accordingly. Assign the right modules and tasks to the right people. Plan time for project parties, trainings and communication related activities. Plan time for reviews – at each level of deliverable and project phase! Plan for tooling and reuse!
Once the plan is ready, share, share and share. Three times, at least. One with the client. One with your team. One with all the other teams including Quality as well as CFG (Client facing group). You will need to have a proper workshop with client and the team to nail down anything that is missing. Quality and CFG will update you in case anything major is missed out. Gather inputs. Talk to all and then revise & baseline the plan.
Anything that forces you to deviate from this plan has to be communicated to all stakeholders – internal and external. The volume with which you communicate and the noise you create should be directly proportional to the deviation from this plan. It does not matter to what level you have to communicate. No one is going to beat you up for communicating more. But you will surely get beaten up for NOT communicating on time.
If you have planned and put together the right level of details, execution should be on fly.
Do we even track them? Do we even know what % of requirements have undergone a change? Do we keep a proper traceability matrix to do a proper impact analysis and then figure out if this change is really a “change” or a defect?
Well, if you have all this info and you can quantify the impact to your plan because of this, no customer will be in a position to force you to take a Change Requests for free. You definitely have to be flexible and if a CR really has to be taken in after appropriate approvals, do so and re-baseline your gospel truth, your project plan.
This takes time. But the more time you spend initially and on each proper activity the lesser time the team and the account management team will spend towards end of the project.
|Posted by Global Learning Labs on March 30, 2014 at 1:30 PM||comments (1)|
Understand subject conceptually.