Monthly Archives: December 2013

8 Must-Have Documents in a Project Manager’s Briefcase

Ok so it’s not the 1980’s and we don’t carry briefcases (unless you work at Wall Street!!) but let’s say there is a shared location on the network where Project Managers can archive and share certain documents with the intended members. What are the documents you are most likely to seed? I compiled a list of essential documents that I deemed necessary to be maintained in an accessible centralized network location by Project Managers as an aid to their project management activities.

  1. Stakeholders Register – This document should contain details of all individuals who are impacted or affected by the project in any capacity and have a stake in the project. It should also state their roles, department, contact information, committee etc.  Certain information such as level of interest, involvement, influence and communication expectations should be shielded from members other than project manager since this information is only for aiding the PM in performing his job efficiently.
  2. List of all team members – This document would state all the members of the project team working on the delivery side. Level of involvement, work packages /tasks assigned, responsibilities, authority and hierarchy should also be included.
  3. Meeting minutes – After conclusion of each meeting there is either a conclusion or a pending state of matters that would need to be documented. The document would basically include the meeting details as well as highlights, outcomes, decisions, concerns, change request, risks etc. that were discussed. It helps stay on track for all the activities that would follow and keeps the attendees on the same page and in agreement. In the event of back tracking by any member it is helpful & easier to go back to the meeting minutes and highlight the notes and action items that were approved.
  4. R.A.I.D Document- This document will have sections for documenting and maintaining risks, assumptions, issues and decisions logged throughout the project lifecycle.
    • Risk Log – This document would contain the detail about the risk, affected components, impact on timeline, level of severity, team member(s) responsible for resolving the risk, action needed, cause of the risk, impacted group, impacted work packages, resolution target date etc. All risks should be numbered uniquely and in the order of discovery and should be referred by that number throughout the project life cycle.
    • Assumptions- This section will list out all the assumptions before the commencement of project and during project execution as you follow through your activities. Every project will have assumption such as availability of required data, estimated disk space for database, availability of required software and things of that nature.
    • Issue log – This section is similar to risk log and would contain list of all the issues numbered uniquely and in order they were received along with the impact of the issue, priority,  affected components, team member(s) responsible for resolving the issue, status indicator, actual reported date, projected completion date, dependencies etc. Entries in the issue log should never be deleted or moved once they are resolved or there is change in status or priority and should have unique id so they can be refereed throughout the project by that id.
    • Decisions- This section documents the decisions taken by any individual authorized in their position to do so, decision details, department/group, date recorded, impacted and affected components.
  5. Detailed Project Schedule – This can be in the form of Gantt chart along with the timelines mapped across various activities. One of the most widely used application is Microsoft Project where in you can list the WBS entries, task name, duration (calculated from the dates), start date, end date, resource name etc. When the cost per effort hour is factored in and added, it helps a Project Manager with budgeting and managing the project P.O.
  6. Team Calendars – This is your team’s calendar where resources will mark their planned vacation, section meetings, training, jury duty, conferences, family/medical leave, flex hours and all corporate holidays. This will help avoid project managers being caught off-guard and especially when your project is on tight schedule and is transitioning into critical activities. It would be detrimental to project delivery if the resources required are not available at right time.
  7. Budget Status Reports – This document would state the breakdown of effort hours booked by your resources, high level project effort hours, translated budget in dollar amount, remaining budget, and burn rate. Budget can also be tracked along with the WBS entries on project schedule document.
  8. Weekly Status Dashboard/report – This deck would contain project status reports like important updates, status color (for ex-green= on track, red= delayed with issues, black=on hold) , work accomplished in previous week, planned activities, important upcoming meetings, milestones, project stage etc. This document can be high level and customized to the need just like any of the above documents.

Spotting a Quality IT Resource

What makes a developer great or stand out among others? Should the focus be solely on their technical skills? To what extent should their other non-technical skills and qualities be factored in?

Project managers know that the success of their projects depend on having excellent developers in their team.  Hiring top notch developers is directly proportional to the success of any project. The next steps revolve around recognizing the right talent and whether the potential candidate would be a good fit in your team.

Conducting interviews involving cross functional team members and assessing the developer’s response to the interview questions is a good start. Theoretical test and mock scenarios helps in gauging their skill sets and interactive practice test could be implemented to validate their technical skills and also of their understanding of the subject in a less technical language. Analyzing their response would help indicate whether their approach and style of work would fit in your culture.

Other pivotal qualities and traits would be assessment of their attitude and desire to perform at a constant high level and delivering the results as per or beyond expectations. The willingness to help and assist while also being able to work independently on per need basis is vital as any work package could either require working within a team or as a sole contributor.

Understanding and being able to seamlessly fit into the desired role and being comfortable & confident with the responsibilities should be a judging factor.

A developer’s sense of desire to grow and contribute with a proactive approach should also be taken into consideration as it allows them to bring new and creative ideas as well as contribute towards potentially bringing in a new line of business. Developers tend to have the highest visibility when it comes to core development work like designing, coding, building components etc. and the developer’s desire to contribute proactively by seeking continuous improvement opens up the door to opportunities for making systems/code better or even propose new initiatives that could make project or project goals better than the planned original.

I have seen numerous times during ongoing project work that an expert developer fueled with a sense of desire in contributing and improving will propose or recommend a different approach, process or design when implemented brings a better value for that particular work product or the end product as a whole.

I am sure there are other vital qualities in an exceptional developer depending on the situation and from a different vantage point of need and desired qualifications. Feel free to leave your thoughts in the comment section below and I will incorporate them into this post if valid.