Weekly ChecklistReflect on the project's progress in a structured and focused manner.
With a project underway, and many, urgent demands on your time, it is easy to lose track of the bigger picture. Use this checklist once a week as a quick check that the fundamentals of a software development project are still attended to.
- Progress checked against plan.
It is now known how the project is progressing against the schedule. This information has been fed back to management. All schedule related issues have been identified.
To bring a project to an on-time, on-budget, everybody-happy completion you must ensure that at all times you know how the project is progressing and what is causing any slippages. Senior management requires, at the very least, a summary of the project progress.
The best way to gather this information is to ask those who are doing the work how it is going. Nothing substitutes for actually asking, face to face - you are much more likely to get a true picture of how tasks are progressing.
- Team members aware of their tasks for the coming week.
Team members know which task(s) they have been assigned to, when those tasks are to be completed, and the dependencies for and on those tasks. Every team member agrees that the schedule for their tasks is reasonable, or has spoken up.
As noted before, we believe that communication is the key to a happy, well run project. An important part of this communication is with the people who do the work.
Project team members are thoroughly annoyed if they do not know what they are expected to do, or when is should be finished. They are also annoyed when they are told to do something that they know they cannot, and are not given an opportunity to voice their opinion. Avoid this justified annoyance. You won't regret it.
- Known Outages Accounted For
Events that will take team member's time away from the project have been allowed for in the project plan.
From time to time, there will be 'outages' in a project that can be planned for. Holidays, trainging, monthly division meetings and server upgrades would fall into this category. While some of these will be known about while the project is being planned, others will crop up over time, and need to be planned for.
- Requirements Change Procedures Followed
New requirements are reviewed, approved and planned for, before development begins.
As project manager, you should at least be aware of new requirements before they are implemented. Many projects suffer from users, business analysts and even technical architects wandering from developer to developer and inserting "good ideas" into the project. While this is done with the best of intentions, it has an impact on the schedule and must be controlled.
- Team Morale is High
The team is working together to achieve the project goals. There is a 'good feeling' to the project.
Aside from the quality of life considerations, a happy team is the basis of a productive team. By 'happy' we don't mean constantly joking around, rather we mean that individuals are content to be working in the team and motivated to achieve the project goals. Such a team will have a 'good feel' to it.
If your team does not have this upbeat, pleased-to-be-here kind of feel to it, you should ask yourself what kind of effect that has on the project, and how you can change it.
- Work "Regular" Hours
Nobody is working long hours for extended periods of time.
Every project will have times when extra effort is required, such as when a deadline is near. However, it is important that work does not consume team member's lives. Not only is too much work bad for people's health, eventually they get sick of it and burn out or quit.
- Troubled Relationships Identified
Inter-personal problems amongst the team members have been noted, and positive steps taken to ensure it does not jeopardize the project.
'Personality clashes', bitchiness and general disharmony are major time wasters, and can usually be traced back to a lack of respect amongst team members for one another. Talking will help, but only if the underlying cause of the problem is identified. As a last resort, separate people who can not or will not get along.
- Correct Skills
Team members have skills appropriate to the tasks they have been assigned.
While it is not always possible, team members should have the skills to complete their tasks in a professional manner. If this is not the case, remedial action needs to be taken: a training course taken, a mentor assigned or more time allocated to the task.
- Shares Knowlege and Skills
The team shares knowlege and skills freely. Team members do not have special tasks that they keep to themselves.
This is partly, an outcome of good team dynamics - if the team respect one another and are comfortable working together working towards the completion of the project, they will tend to share their skills and knowlege with one another.
However, even the closest-knit team may need encouragement to start sharing knowlege and skills. Consider assigning people to work together on certain tasks or assigning people unfamiliar tasks in order to force them to ask for help.
If the team is not sharing knowlege in this way, the project will tend to fragment - only Bill can do task X, and only Frank can do task Y - and bottlenecks form in the schedule.
- Building Consensus
The team is developing a consensus on procedures and standard for everyday tasks.
A further consequence of good team work is that standard ways of doing common tasks will emerge. This is a good thing since it leads to standard, repeatable processes.
Sometimes, a team will need a nudge to get them started. This may take the form of a meeting to discuss coding standards, or having someone document a procedure and then elicit comments.
Build and Deploy
- Regular Builds
Nightly builds are being performed.
Regular, nightly builds encourage developers to integrate their changes back into the source code base as soon as possible. The more often developers integrate, the smaller integration problems become.
- Builds Not Breaking
There are usually no compile errors in the nightly builds and automated test harnesses usually complete without errors.
In addition to just doing nightly builds, the quality of the output of these builds should be checked. An effective way of doing this is to first check that the code actually all compiles, and then passes a series of automated test harnesses.
If the code regularly fails to compile and/or fails to pass the automated test harnesses, then it is a good indicator that developers are not properly integrating code. The sooner integration problems are fixed, the better.
- Have Relevant Requirements For This Week's Tasks
Team members have enough information to complete the week's tasks. For software developer's this means having firm requirements and/or the means to resolve questions about what is required.
- Configuration Management Procedures Followed
The team members (usually) comply with the configuration management procedures.
If the configuration management procedures are not followed, it is a fair bet that the development team is not getting the benefits of the configuration mangement system: they cannot reconstruct a build, cannot properly coordinate multiple development streams and cannot categorically state the versions of components that make up the released system.
In this case, you have three options: abandon configuration management altogether (not usually a good idea), write new procedures or enforce the existing procedures.