“Hardly any faculty is more important for the intellectual progress of Man than ATTENTION. Animals clearly manifest this power, as when a cat watches by a hole and prepares to spring on its prey..."
Charles Darwin, ON THE DESCENT OF MAN, 1871
Below is a list of items to think about when starting up a project. There is an assumption that the project has been sold and now the focus is on setting up the project to deliver against what was in the contract and reducing the execution risk during the project.
1. Did the pre-sales team do a handover to the delivery team?
2. Did they follow any checklists
3. Were any issues identified?
4. Is the delivery team ready?
5. Is the customer ready?
6. Is the project big enough or is it high risk, that would justify setting up and an internal steering team?
7. Have the meetings been booked with the right stakeholders?
8. Is the delivery team going to follow a standard delivery methodology?
9. Has it been used before, does the team have experience in using the methodology?
10. Has a shared work space been set up to store the documents used during the bid phase. For example the signed Statement of Work (SOW), the project plan, any business requirements from the customer, the budget estimates or templates that were used to price the project. For an SOW template go here.
11. Is there a Project Management Plan (PMP) created which will describe how the project will be delivered? Has this been reviewed with the customer? Basically the PMP is the playbook that describes how the various teams involved in the project will work together.
12. Have the key stakeholders been identified. This should include project stakeholders who will be involved in the delivery of the project as well as customer stakeholders who will approve and accept the project deliverables. In addition it is often prudent to engage with the end customer stakeholders or the business as these are the people who will accept the solution and who have often providing the funding for the project. Business stakeholders will often delegate to the IT department to manage and deliver the project but they should be kept close to ensure alignment between business and project objectives.
13. Has the Statement of Work (SOW) be signed by both the customer and the supplier?
14. Has the project scope been documented, reviewed and signed off by the customer in the SOW and does the SOW include payment milestones and the customer's responsibilities. For example the customer may be responsible to provide some project resources.
15. Have the assumptions, exclusions and dependencies been documented in the SOW?
16. Have all external dependencies and constraints been documented in the SOW and included in the Project Management Plan?
17. Are all deliverables clearly described and identified, with measurable acceptance criteria and, signed off by the customer? Acceptance of deliverables is very important and the statement of work should define for each deliverable what will be the acceptance criteria. For example detailed design might be accepted by signing off the detailed design document after 2 review cycles. Testing might be accepted after the test report is produced showing that there are no outstanding severity 1 or 2 test defects.
18. If the project includes migration of data or applications, have they been scoped, priced and planned?
19. Has a commercial model been prepared that is in line with the project schedule and covering all project costs. For a useful template go here.
20. Are signed purchase orders in place between the supplier and the Customer, and the supplier and subcontractors, and are all authorised changes covered by a signed purchase order?
21. Are contracts with other suppliers documented?
For a more detailed list of things to consider when pricing a project, you can read more here.
22. Are requirements tracked from the contract, through functional or design deliverables to test specifications? Is there requirements traceability matrix?
23. Is there a change control process documented. This can be included in the Project Management Plan (PMP).
24. Have change control boards been set up and is there an up-to-date change log?
25. Does the project have a current schedule with an appropriate work breakdown structure that defines the tasks or activities that will be done during the project?
26. Is the schedule being maintained? That is, are there regular reviews set up, often through a weekly core team meeting, to update areas like % complete, tasks, resources?
27. Has the schedule has been base lined? Often when starting, if a project is not base lined it can be hard to measure the impact of any changes or delays.
28. Are customer deliverables or activities on the schedule? This is important so that the customer can see what they need to do and when. All too often projects can suffer delays due to customers not being aware of the work that they need to do and when they need to do.
29. Are external dependencies and milestones included in the schedule?
30. Do all schedule tasks have resources allocated? It is important not to over allocate resources. Tools like Microsoft project can provide very useful reports on over and under allocated resources if the schedule has been built with that level of details.
31. Is the critical path identified in the schedule? That is are all the tasks linked.
32. Is the schedule sufficiently detailed with work breakdown structure (WBS) and tasks that will allow a project manager to manage the project ? If there is not enough detail there is a risk of scope creep and cost increases as tasks and activities which were not planned are added to the schedule.
33. How are costs being tracked and measured?
34. Is there an Estimate to Complete (ETC) forecast being updated regularly?
35. Is the ETC consistent with forecast costs, project schedule and deliverables?
36. Is revenue being earned in alignment with the company revenue recognition policy? For example some companies recognize revenue as costs come in from people booking time to the project, some companies only earn the revenue when the project milestone is accepted.
37. Is the project margin still on track?
38. Are staff recording actual hours worked against the project? Are they recording too much?
39. When a change request is requested, is the change request evaluated in terms of the impacts on scope, schedule, cost, sub-contractor, risk, and contractual and SOW compliance?
40. Does the project have a way of measuring and keep tracking of key project health outcomes. For example having a Measurement Plan that captures the goals, sub goals and the associated metrics with the project. A good place to define this is in the Project Management Plan (PMP).
41. Does the project have a Quality Plan? Again this may be part of the Project Management Plan (PMP), and are regular assurance activities being performed as planned. For example has the project manager scheduled design or requirements reviews to be done with customer; code quality checks planned and executed; peer reviews planned and executed?
42. Is there a Project Management Office review included in the schedule?
43. How is the software quality being managed?
44. Does the project have a way of managing code configurations? Is there a 3rd party tool that needs to be updated?
45. Are standard procedures in place to control all of the data that support the project?
46. Is the use of any client required templates documented?
47. Is there a centralised file or collaboration area that that contains the original paper and or digitally scanned copies of the original signed contract documents and all approved deliverables? Having a central repository is important to maintain consistency as the project progresses and there may be staff additions, moves and changes. It should be the single source of truth for the project.
48. Is the central repository being backed up and not just stored on the project manager’s laptop?
49. Have design and requirement reviews been conducted with the customer? Does the customer know when they are and will they have staff available to attend and provide appropriate feedback.
50. Is the status of deliverables being accurately tracked? For example key deliverables like a test report indicating completion of testing should be stored in a deliverables file and tracked for percentage of completion.
51. Does the project need a development environment?
52. Has the development environment been defined, sized and built
53. Does the project need a testing environment as well? Does the project need a pre-production environment?
54. Does the project need extra software to stand up these environments?
55. Who is expected to build these environment? Who will control and maintain, including backing up these environments Who will grant and maintain access to the environments
56. Has a Test Strategy and Test Plan been defined and agreed with the customer. Does it include test specifications and test cases?
57. Is there a comprehensive acceptance test plan that has been signed off by the customer and which clearly defines the roles and responsibilities of the supplier and the customer?
58. Is there a defect tracking system in place?
59. Has the test exit criteria been defined? Usually this would be through the expression of a level of coverage of test cases, for example 100% of test cases in a six week period, and then a quality level by specifying that there are no severity 1 or 2 defects and an action plan to close the severity 3 and 4 defects within X months.
60. Are roles and responsibilities defined and communicated to the team?
61. Is there a RACI documented which defines Responsibilities (R) Accountability (A) Contribution (C) and who is to be Informed (I)?
62. Has the RACI been reviewed and approved with the customer?
63. Is there a current Project Organisation chart that shows all stakeholder?
64. Are plans in place to deal with key resource turnover? What happens if a key resource leaves?
65. Is the technical skill set of the team appropriate to deliver the project?
66. Have all the planned resources been identified and assigned by the due dates and are resources sufficiently skilled to deliver the project. Does the customer want to interview project resources. This may only be appropriate in Time and Materials based projects. For a fixed price project the customer is buying the outcome not the resources. However the customer may still want to specify a certain level of competency from the supplier and may ask to see CVs and bios for key project resources, including the project manager, change manager, solution architect.
67. Are there any security access issues to be managed?
68. Will staff get their security access in time to allow them to work on the project?
69. Do project resources need training?
70. Is there an on-boarding plan?
71. Is there an Occupational Health and Safety (OHS) plan to on-board project staff to a particular work site?
72. Are there appropriate work site resources including desks, communications, wifi, network etc.?
73. Was an internal kick-off meeting conducted?
74. Was a customer kick-off meeting conducted?
75. Is there a documented Communication Plan (may be part of the PMP) and was this signed off by the customer?
76. Is project status communicated to the team?
77. Are there regular core team meetings?
78. Are there management or steering committee review meetings with the customer, and are minutes of the meeting being recorded including a decision log or register?
79. Are written status reports provided to the customer that accurately reflect the status of the project (schedule, risk, issues, payments, customer invoices, and change orders?
80. Are there regular review core team meetings with the customer, and are meetings documented and minutes published?
81. Is an action and issue management process and log in place that includes the customer and 3rd party issues?
82. Is the action and issue log reviewed at appropriate intervals? Are late items addressed and are owners and completion dates assigned to actions?
83. Is a documented escalation process in place and is it used effectively, both internally and with the client?
84. Is there a Risk Management Plan?
85. Was the entire team involved in risk identification (e.g. a risk workshop)?
86. Is the Risk Log reviewed and updated on a regular basis, and does it clearly describe individual risks?
87. Are individual risks clearly described and quantified in terms of their probability and likely impact?
88. Are risk response plans in place for high priority risks and are the response plans being executed and maintained?
89. Are defined risk mitigation plans being carried out?
90. Where risk reserve amounts included in the cost estimates?
91. Are signed subcontractor agreements in place, including a list of deliverables with acceptance criteria established, quality standards and a documented change control process?.
92. Are regular reviews carried out with the subcontractor and does the subcontractor report status at the required intervals?
93. Are subcontractor activities integrated into the schedule?
94. What resources does the customer need to allocate to the project?
95. What skill level do those resource need to have? And have they been allocated?
96. Is the customer meeting their obligations?
97. Is there a formal channel for customer satisfaction feedback and has this been measured periodically?
98. Is the feedback appropriate?
99. Is the customer satisfied with the schedule; quality of deliverables, communications, technical ability of the team, overall project?
100. Are there end customer or perhaps business users who need to be consulted on their satisfaction?
101. Have you forgotten anything?
If you would like to subscribe and have these emailed to you, you can do so here.
All the best and thanks for reading.