Start with the Project Definition
My first reference point is to read the Project Definition document as this is the foundation of any Project. Checks I make include:- Is it signed off and by who?
- Objectives clearly stated?
- What are the project constraints?
- Is Scope clearly defined?
- How is quality defined? e.g. acceptance criteria, standards etc
- Is the Project Owner (Sponsor, Project Board etc) defined?
- Have other stakeholders been identified?
- Has the Project Team / Organisation been defined?
- Are the Products to be delivered by the Project defined and is there any defined Quality plan?
- What Plans are in place and assess how much these plans Droop in quality?
- What budget has been defined?
Look for the Business Case too
- Is there a Business Case?
- What is the linkage between the Business Case and the Project deliverables e.g. specific requirements to be met
How has the Project progressed against the plan as stated in the Project Definition (Evidence of Monitoring & Control)?
- Is there a well organised Project File?
- If so, have a look for some of the key Products (Deliverables) which the plan says should be delivered at this point in time. Assess the quality of these
- Is there an audit trail of regular (weekly?) status / highlight reports? If so read a selection to get an overview of how progress has been reported (hopefully this is in line with what you have checked elsewhere) and their is evidence of Monitoring and Control
- Is there a forecast spend and how is that derived?
- Are costs being monitored?
- What means are there to discuss progress with members of the team - internal reporting, regular meetings etc?
- Is there evidence of Risk, Issue, Assumption and Dependency Management?
Evidence of Project Governance happening?
I will look for evidence of good Governance processes in place
- Are there future Project Board meetings in the diary?
- Is there evidence of previous meetings - Project Board Packs and Minutes/Actions?
Above all - listen to people
You should organise meetings with various stakeholders and key Project team members, fire some open questions and listen to how they respond. This should reveal useful information and views about the status of the Project as well as attitudes and the human side in general
Conclusions and an Example
You have made your assessments and you need to need to decide what remedial actions are required, if any. Sometimes you may need to have some hard discussions with your Sponsor and Project Board. You need to do this in the first few weeks before your "honeymoon" period has ended.
I remember one in-flight IT project I picked up for a new system development and assessed there wasn't a 1 in 100 chance of making the "planned" delivery date even with remedial actions despite the project being reported as on track. I had "the hard discussion" face to face with the Sponsor to say this and stated that I would replan, descope some functionality to deliver the remaining key functionality as soon as possible (I gave him an approximate date and confirmed within 2 weeks) and essentially prove the team could deliver something versus cancelling the whole project.
Clearly he was not happy at all but eventually agreed to this approach. Based on good evidence of progress towards hitting the delivery date (which we did), he agreed the additional funding to deliver the Release 2 (the remaining functionality which was de-scoped from Release 1). So a (reasonably) happy Sponsor in the end and a Business Case that was not too badly compromised.
1 Comments
Thank you so much for this helpful article, Its a friendly reminder for me to look out for a whole lot of things before proceeding to take on an in-flight project.
ReplyDelete