Project Management Simplified For Technical Groups (Part 2 of 2)
Welcome back to Part 2 for an explanation of the different parts of the template and why they are needed. Please refer to the sample project timeline at the bottom of the blog for the location of the numbered items in brackets [ ].
 Every project needs a title to accurately reflect the nature of the project. Between the project title  and the project description/scope  there should be no confusion regarding the deliverable(s) of the project. If it is not clear, keep modifying one or both items until it is or the project will likely fail. Also, put in the date so the timeline reflects the approximate beginning of the project plan.
 Project Leader. Every project needs an owner and someone to help drive the team towards the finish line. This is typically the ‘keeper’ of the file and the person making approved updates. If you prefer to add other team members’ names there is room to do so.
 This is the project status as of the current date is shown by the red ‘Today’ marker of planned work versus completed work as determined by the Project Leader. The marker helps visually determine if the project is on time, slipping, or late. It is the duty of the Team Leader to re-print the project just before each review meeting to allow the ‘today’ marker to slide to the current date. This will clearly show that milestones to the left of the marker should be completed, and milestones to the right of the marker are still on schedule. If milestones to the right need to be re-scheduled, a Reason for Change  should be requested and approved by the supervisor. Failure to re-print the timeline will show an incorrect status of the project and is typically ‘missed’ to prevent changing the true status to yellow or red.
 This is the project timeline along with the start and finish dates, milestone descriptions, and ‘Today’ marker.
 Project Description / Scope. This area should accurately reflect what the project is about, the deliverables, and perhaps what it is not going to cover. Out of scope information can help to prevent project creep.
 Reason for Change. This is a critical area as the project leader should need a valid reason to make changes that require an extension to the project due date and document the change. It is also a highly recommended practice that their supervisor must see and agree to change(s) prior to updating the project timeline. This reduces continuous undocumented changes by project leaders that are not properly following up on their projects and are not interacting with other support groups/peers doing what needs to get done per the agreed upon timeline. It also documents any major company issue(s) that may divert manpower requiring the project timeline extension. Approved updates can be tracked through the use of revision changes for business needs or regulatory requirements.
 Each time there is an approved Reason for Change, the document Revision (REV) should be updated as well as the date. Example: from REV 1 07SEP2015 to REV 2 15DEC2015.
This is the type of timeline that has successfully worked for me in the past. I hope it can work for you also. If you have any suggestions or comments please feel free to send them via the Idea Box. If you would like to receive weekly notices for new blogs just add your email in the ‘Subscribe’ section on the right and click the ‘Subscribe’ box. Good luck!