Project Management – Words of Wisdom to the Uninitiated

So, you’ve got your first job as a Project Manager (PM) – congratulations.  Now, you’ve been assigned your first project and you’re looking at the elephant thinking to yourself, what do I do next?  Well, jump in with both feet seems like a good idea – but which end of the pool and how do I tread the water to keep my nose above the waterline?  I’ll attempt to give some advice in this posting – take it for what it’s worth, it may not work for you or your organization, but you may be able to find a nugget in here that gives you a ray of hope!  I know that it has helped me and those individuals that I’ve mentored over the years.

So, most development projects are broken down into phases along the following lines:

1. Discovery – this phase allows you to identify the stakeholders of the project and then working with the stakeholders identify the boundaries of the project, what will and won’t be included in the overall scope of the work.
2. Requirements – this phase allows the team to clearly identify the requirements associated with the project – this should include functional and non-functional requirements.  By the way, this is a personal pet peeve of mine – if requirements don’t include at least a high level explanation of how the user will test/validate that the requirement, then the requirement is not complete.
3. Technical Design – this phase of the project allows the technical side of the organization to take the requirements and translate them into an overall roadmap that identifies the application silos that will be touched and how everything ultimately fits together – this is the roadmap that technical teams will use to build the applications and underlying infrastructure.
4. Development/Construction – this phase of the project allows the teams to construct the functionality that will be delivered as a result of the project.  This should include not only the technical pieces, but the business pieces as well – marketing plans, supporting documentation, etc.
5. Testing – this phase of the project is used to confirm that we have not broken current functionality and that we have validated that the new feature/functions work as documented in the requirements and the technical design.
6. Implementation – this phase of the project allows the teams to move the application and underlying infrastructure changes into the production environment.

Clearly, looking at all of this when you’re first assigned to a project can be overwhelming.  As a PM, how do I know what tasks to put in the project plan and how long do I have those tasks last?

Really, this becomes much simpler than it looks – let’s take the first phase, Discovery.  We understand what needs to be delivered within this phase of the project – in most organizations, it will look something like the following:

• Project Request Document – gives the background justification for the project, a very high level scope of the project used to inform others what is being delivered, extremely high level expenses/costs, extremely high level sales goals, and competitive information.
• Project Concept Document – once the project request is signed off by the stakeholder, this document dives down to give more details – if the project request document was the 100,000 foot view, this takes down to the 50,000 foot view and includes things like the formal project scope/boundaries, project needs analysis, market assessment, proposed timeframes.
• Vendor Due Diligence – this activity confirms that viability of outside parties to deliver critical components of the project.
• Business Case – this takes the Project Concept and builds the other components around the base to provide management with the complete picture allowing them to make the go/no-go decision - sales commitments, revenue projections, product demand and strategic fit information.

Other organizations may drive more or less artifacts through the Discovery phase of the lifecycle.  All that being considered, there are a base set of deliverables that are expected at the end of the Discovery phase.  Additionally, it’s not just a matter of the deliverables/artifacts being generated, it is disseminating that information to the decision makers and getting direction on the go/no-go decision.

So, let’s work backwards – let’s say you’ve been given 3 weeks to perform this activity.  You know that you have to have a meeting with the decision makers at the end to review the information and get the go/no-go decision.  You know that the expectation is to deliver the necessary artifacts 3 days before the meeting.  So if you have a 3 week timetable – that’s a total of 15 business days.  Assume the meeting with the decision makers is held on the last day, that means the documentation must be delivered on the 12th business day.

As the PM, you need to have the following discussions in your phase kick off meeting:

• Who needs to be included in meetings to create each of the deliverables/artifacts – Project Request, Project Concept, Vendor Due Diligence and Business Case?
• We have 12 days to complete each of the artifacts/deliverables for the Discovery Phase – how often do we need to meet on each artifact and how long should each of those meetings last?
• What are the check points in each of these meetings to ensure that we are on track to complete the documents in the required amount of time?

Now you have a timeline to work with – 12 days – and it becomes a matter of accountability.  Setup the meetings, ensure people are attending and contributing.   Your markers for each meeting – make sure you have an agenda, then take and distribute notes:

• Validate that the work that was supposed to be done between meetings was completed.   Get proof – sorry, I tend to be skeptical.
• Review agenda items – check off those items completed, note those not completed and create action/agenda items for next meeting.
• From the review of agenda items – when looking at items that were not completed, are there new risks/issues that need to be highlighted and mitigation plans created or does someone just need to catch up on work assigned?
• Review status updates across the team – ensure people are highlighting what is needed from each other to complete activity needed in this phase of the project.

Sounds simple, right?  Now, as a PM, it’s your responsibility to not to be surprised in your meetings.  While you may be meeting with parts of the team several times a week and the whole team on a weekly basis.  It’s your job to stay on top of things between meetings.  You should never walk into one of the meetings you are holding and have it be the first time you hear that someone is behind schedule.  You need to be performing walkabouts – moving around on the floor, instant messaging, or calling people to discuss how they are doing, what’s working, what’s causing them problems and staying on top of activity.

If between meetings, you become aware of a roadblock – it’s up to you to find ways around, under or over the roadblock and allow people to continue to move the process forward.  Who can you bring into the discussion or work activity to help the person forward?   What work activity can be reassigned?

Now, rinse and repeat for each of the following phases.  The difference being that at the end of the design phase, you should be able to obtain feedback from the team identifying all of the remaining tasks/milestones and timelines for the project.  This then becomes the baseline that you measure everything against.

Tags: Project Management; Software Development Lifecycle; SDLC; Change Management;

For more information on David L. Collison: LinkedIn Profile