Search This Blog

Monday, April 30, 2012

Guest Post: Comparing Project Management Systems for Software Development Projects

By Steward Copper

Managing projects correctly means combining science and art! Managing projects successfully means creating a team that will produce the required commercial product and, thus, will fulfill its mission. An effective leader manages a team presenting a symbiosis of technical solutions and managerial methods in his work. Many specialists in the sphere of web programming have already formed their own opinions about the advantages and disadvantages of different project management systems.

Most developers claim that the choice of an ideal project management system entirely depends on the mission that the team has to fulfill. For a long time, specialists have been discussing the evolution of the new culture of concurrent web programming automation. Among the most interesting software solutions I have found are the following:

Redmine ( is an open server web application for managing projects and tracking bugs. Redmine is written on Ruby and represents an application based on the widely-used web framework Ruby on Rails.

Redmine features:
  • Flexible access system based on roles;
  • Bug tracking system including submission of bugs by email
  • Maintaining project news, documents and file management as well as creating forums and wiki pages of projects;
  • Reporting on changes using RSS flows and e-mail;
  • Adjustable derived fields for incidents, time expenses, projects and users;
  • Simple integration with version management systems (SVN, CVS, Git, Mercurial, Bazaar and Darcs);
  • Database management system support (MySQL, PostgreSQL, SQLite, Oracle).

Redmine drawbacks:

  • In Redmine you can’t manage access rights at the level of individual task fields. For example, at present you can’t hide subsets of information such as estimated hours or actual hours from clients.
  • One can manage access rights at the level of projects but can’t assign rights for some versions of the project or individual task. It means if a user needs an access to one task , he will also need to be given the access to the whole project.
  • If a user in Redmine gets access to the project, his activity can’t be limited to certain tasks only. For example, it’s impossible to allow viewing or creating tasks only of a certain type.
  • Task delegating is not available in Redmine — a task can’t be delegated to another executor.

Easy Projects .NET ( is a web application for managing software development projects written on .NET by Logic Software Company.

  Easy Projects .NET features:
  • Easy Projects .NET allows creating unlimited number of projects containing various adjustable fields. Batch processing allows performing typical operations for several projects simultaneously.
  • Gantt chart, interactive graphs and reports are available for users.
  • Easy Projects .NET supports unlimited number of tasks and sub-tasks as well as the adjustment of statuses, categories and task priorities. Creating tasks by e-mail is also supported . Both developers and clients can add requests and requirements.
  • The program supports  tracking paid and unpaid time spent on the project. Personal and corporate schedules are both supported and  you can also view the resource workload schedule. Flexible administration  of access rights is also supported.
  • Easy Projects .NET makes it easy to generate invoices, budget tracking and required custom reports .
  • The program supports data exporting to MS Project, Excel, PDF and iCal, integration with Vyew, QuickBooks, SmarterTrack, Dbxtra, as well as synchronization with Easy Time Tracking.
  • The program interface can be customized by adding or deleting widgets with the information on your projects. Users can use web conferences for concurrent work. The user interface supports English, French and Russian languages.

Easy Projects .NET drawbacks:
  • Assigning the team members’ level of training is not available;
  • No reliable means for tracking material resources is available;
  • No tools for risk analysis are available;
  • No mobile version of the program is available. However, modern mobile devices (iPhone, Blackberry) allow displaying usual sites quite well and give a possibility to use the given program without restrictions. 

Atlassian JIRA ( is a software solution from Atlassian Company for managing the lifecycle of any project or working process. This system is suitable for simultaneous work with tasks in the framework of a business process or project. The system allows working with several projects, dividing them into stages, assigning various types of tasks, connecting tasks, appointing responsible people, adjusting roles, generating reports, etc. JIRA works via the browser and doesn’t require software installation on the user’s PC.

JIRA features:
  • The system is scalable and suitable for small and big companies.
  • There are built-in options for for bug and task tracking;
  • Project support and maintenance;
  • Task tracking;
  • Requirement management;
  • Working processes / Business process management.

JIRA drawbacks:
  • Displaying takes place after some time. Thus, the less time passes between requests, the more often the repositories will be requested, which will affect the efficiency of the program;
  • Ticket searching takes place in all repositories — consequently, if you have a large number of repositories, the performance of the application is reduced;
  • It’s impossible to connect a repository to the certain project;
  • The program doesn’t prohibit introducing a comment into a non-existing ticket.

Comindware Tracker ( is a corporate software solution for effective task tracking and managing daily processes and tasks. The Comindware solution is based on the ultra flexible technology ElasticData™ which allows managing business processes with extreme flexibility. Comindware Tracker includes free Comindware Task Management™ and the technology ConnectStep™ that allows automating the process of generating tasks for the next step and optimizing their execution for any business processes within any department or several ones. 

Comindware tracker options:

  • Automated task creation;
  • Changing processes on the fly without losing data; 
  • Flexible reporting function: easy adjustable lists, graphs, filters and groups;
  • Various resource accounting (material and informative resources) and interactions between them; 
  • 100% web-based solution.

Comindware tracker drawbacks:

  • No mobile version is available but the company promises to have it released by the end of the year;
  • The software is comparatively new so it may not be tested properly;Most programmers are still unaware of this software so additional training may be needed.

Of course, this list is not complete and some developers prefer using their own project management tools for achieving their goals. My goal was sharing my experience and presenting the various project management tools and systems used by our company.


Hi, my name’s Steward Copper and I am the owner of Project Management Insights. While working as a project coordinator and BA, I have tried almost all possible PM tools, BA instruments, collaboration programs, including tracker and task management software solutions. I also write for different blogs sharing my knowledge and observations.

Wednesday, April 25, 2012

Project Planning 1.1: Project Tracking - Plan for it Now!

[Also available as a Podcast]

Project tracking is an important element of control on any project. During the project, you need to be able to measure and report on progress against project deliverables, and roll-up that information into higher and higher levels, until you often end up with a high-level dashboard for the Project Sponsor and other executives (red light, green light, yellow light). And in the long run, you need to be able to know when you have actually finished the project, and if you have succeeded in achieving the project goals.

Sounds straightforward, right? But as you probably already know, it is not quite so simple. There are many projects that do not track enough information, and others that track too much. All of this tracking requires effort, by the individual team members, their team leaders, the Project Manager, and those who receive the status reports.

Asking people to spend "overhead" time on activities like status reporting when they do not see any direct relation to what they are doing, and how it is used can be another big problem - if they do not see value in doing it, it becomes a "chore" that they would rather not do - so they may delay doing it, not do it at all, or worse, "fake it".

Sometimes all that effort results in only a cursory glance at the highest levels. So why bother with it? Or the information can become so disassociated due to poor structuring when it is rolled up that it becomes effectively meaningless. This problem can be a related to how you have structured your Project Plan, and also your approach to tracking. That, of course helps nobody.

So what do we track, how do we track it - and most importantly, how do we plan for it and what do we do with it?

In this session we will explore the essentials of Practical Project Tracking - what you will need to manage your project, satisfy the reporting needs of your stakeholders, and be able to tell, in the end, if your project was successful.

Practical Project Tracking

Note: I have introduced this topic immediately following the Project Kickoff rather than leaping straight into Project Plan development, because deciding what you are going to - and how you are going to track it - go hand in hand. If you build the Project Plan and then think afterward about how you might track it, you have actually started backwards and may need to do some re-structuring. You need to be prepared and thinking about tracking first - before you build the detailed plan.

If you have read any of my other articles, you will know that I like to keep things simple. I have managed some very complex projects, so it is not the projects that are simple - but any processes you use within the project team should be simple, clear and easy to follow. Make something simple and people might actually use it. Make things complicated, and you are fighting a losing battle because people will resist it. They may make a half-hearted attempt to do it at the beginning, but usage will generally fall off over time. Or the number of errors introduced because people do not understand it or how to use it will soon make any information collected unreliable.

In fact, I like to think that the more complex the project is, the simper the processes the PM introduces need to be. People's heads will be so full of all the other complex detail, it can be a relief to follow some simple steps a few times a week. They might even come to enjoy providing status to you! (Well, OK, maybe not - but they will be less likely to see it as a burdensome chore).

So keep it simple. But in saying that - you can produce some very complex statistics and other project measures using data that is collected with simple processes - so this is by no means "dumbing it down".

1. Why Track?

There is an old saying that goes "you get what you inspect", or alternately "you get what you test". If you have no way of determining what is happening on the project, what has been completed, and what issues there are that might trip you up, how can you make sure you are on track? If you are not looking (or not looking in the right places), things will continue along quite merrily - until they sail right off the cliff.

The basic purpose of tracking, put simply, is to be able to answer these three questions:
- Do we know where we are now (what we have done up to this point)?
- Are we still going in the right direction, and what obstacles might be in the way?
- How will we know when we get there?

If we have enough information to answer these three questions, whatever form(s) it might take, then we can take corrective actions if necessary, and fine tune the next steps to catch up, and/or to keep the project on track.

Another aspect of tracking and measurement is analysis/review - no point collecting information if you are not going to do anything with it. The Project Audit may see a clear path to failure in your detailed records, but it is better that you use the best information available to stay on top of things and, like a GPS, do minor course corrections as you go - vs having to backtrack a long way when you have gone too far off the planned route.

1a. Ask the Question: Why do you need it?

The next thing you need consider when planning to track your project is: "What will we do with the status information?"

"Easy" you say - "we use it to manage the project." Well, yes and no. You need to consider your stakeholders - yourself (as the PM), the project team, the Sponsor, and any other key people in your Stakeholder map that are (A)ccountable or that need to be (I)nformed on the progress of the project, and made aware of any issues that need to be escalated to them, decisions that need to be made, etc.

Your reporting requirements may be for two main groups (the Project Team and "the Sponsor and all the rest of them"), or you may have several distinct groups that you need to report to. The information that you need to provide may also differ from stakeholder group to stakeholder group.

Let's consider this further.

- As the PM, you know what types of information you typically collect on a project "of this type" to ensure you have enough information, in a timely enough fashion, to make sure the project stays on the rails, moving in the right direction, and that you still look to be "in scope/on budget/on schedule" etc.

- The others are a little harder. You might guess at what they might want, because on the last project the stakholder groups, the sponsor etc all wanted particular information. But a better idea is to ask them what they want. Each stakeholder group may need different slices or views of information - some may want to just see the financials to-date. Some might want to see overall progress as %completion, and the CEO may just want a red/green/yellow dashboard. Give each group exactly what they want - and not more than they are asking (at least for now - they may refine their reporting needs later). You should also ask them how often they want the information reported (weekly, bi-weekly, monthly, quarterly, etc).

Still not clear on what they are looking for exactly? Ask them to provide you an example from another project, or have them draw it out for you (or they describe it, you draw it, and they validate it). You may find out that the information they require might actually affect the evolving stucture of your project plan. (They may want overall or detailed status by particular stages of a long-term project, or by major deliverable groups, etc). The more you know now, the easier it will be to make sure that your project plan/WBS meets your needs - but also does not become a headache when trying to report to stakeholders.

Tip: This will become an important part of your Communication Plan.

Once you have a perspective on what the different stakeholders need, plus what you need to manage the project, you are in a much better position to figure out what you do - and don't  - need to collect in terms of information, and how you might go about structuring it. You may find that you can simply "roll up" detailed status in the project plan to satisfy some of their needs. Or you might need to do some more typing - i.e. if they need to take action on anything in the CRAIDL, particularly Issues, Decisions and Risks.

Note: We won't cover the actual Project Plan development in this session, so just keep this information on tracking in mind as you think about your project plan.

- Who needs to provide the information? This may seem obvious, but take some time to think about it. Is it the Team Lead? Or the individual team members? Or more likely a combination of both? I suggest that it depends on what the information is, and also what tools you might have available.

For anything in the CRAIDL, the updates will tend to be "textual" - that is, not firm facts and figures, but descriptions of the issues, risks, decisions that need to be addressed, or are holding things up because they have not been addressed, and the status/disposition of previously raised items. This type of information is more suitable for the Team Lead to collect and provide to the PM on larger projects; if you have a smaller project then each team member could be doing this themselves.

For progress updates against the plan tasks/deliverables, either effort-based or calendar-based, ideally this will be fed back into the project management tool "at the source". I don't tend to trust progress updates that say "55% complete" as the sole measure; often the percentage is based on gut feeling and is not meaningful. However, "projected delivery date" and "actual hours" are generally more useful measures. If 48 hours of an 80 hour estimated deliverable have been  expended on the task we can calculate 60% completion. (Sometimes it might not be, example for a deliverable that involves initial delivery and test/revision cycles, the overall estimated hours is not useful for seeing if the "first delivery" is on track; you would need to break it down).

A note of caution: Some sponsors/stakeholders tend to ask for specific information "on every project" the same way, every time. Do not be afraid to challenge them to think about what they really need this time - they might in fact need all of it, or they might only need a part of what they normally ask for on this project. Just asking this question can save you hundreds of hours of effort if you are producing status information that is not actually used. In addition, you will get better sponsor/stakeholder involvement and participation - because they see you as caring about what is important to them, and that you are being a good project steward and efficient with their time and the project $. 

Of course, this could end up with you providing more information than they previously had, depending how your discussion goes. But if you are a clever and practical PM, you will offer up metrics and information you are already needing or planning to do anyway. And they may be so delighted with your suggested status reporting that makes their lives so much easier, they may take you to lunch - or more importantly, approve the inevitable change requests you really need later on without too much trouble.

2. What should we Track?

Well, there are many things you can track. There are any number of formulas for calculating project status, ROI, progress and performance. The ones you will need to use will depend on the reporting needs for your project. You can get pretty sophisticated - even with some basic data points. Note: This is not a discussion on the application and use of those forumulas - there are a number of very good books on the topics of advanced measurement and analysis.

There are three main types of information that can be collected/measured:
a) Hard data (dates, hours, budget vs actuals, defect rates, number of versions, etc)
b) Objective information (Risks, Issues, Decisions, Descriptive status reporting)
c) Subjective measures (customer satisfaction, "mood" of the client, etc).

On a project of any significant size, you will need to consider all three categories; for smaller ones just the first two.

Hard Data Measures
At the simplest level, information is commonly collected for the following
- Completed tasks/deliverables [to date, or this period]
- Tasks/deliverables in progress
- Tasks/deliverables coming up next
- Actual hours expended (to date) vs Estimated
- Actuals vs Budget to date
- Deliverable progress vs estimate (we are going to be 2 days early, or 7 days late) 
- Progress by duration (half the time is spent, we should be half way to completion, or not)

Objective Data Measures
The other important things to remember to track, manage and get updates on regularly are in tucked away in the CRAIDL.
Constraints: Any impacting the team that need to be discussed?
Risks: any new ones identified, or recorded risks have occurred (Risk Event) or are more likely to soon?
Assumptions: As we go through the project we may need to correct assumptions or add new ones.
Decisions: Are there new ones that need to be made? Any outstanding that are holding up progress? What were the results of the recent decisions? etc.
Lexicon: This may seem a minor detail, but if there is new jargon, buzzwords or acronyms, remember to update the Lexicon. This will also feed the Communication Plan.

Subjective Measures
On longer projects, you will generally need to do some periodic subjective measures such as customer satisfaction, client or department/stakeholder group mood, and perception of deliverable quality. There have been countless projects that have delivered to specification, on time and on budget - and failed because it did not meet the subjective success measures. Of course we are not saying scope and requirements are irrelevant - they most definitely are not - but if you have a finger on the overall pulse of the client, the stakeholders/end users and pay attention to the big picture, you may have a better chance of introducing or getting a change request approved that will end up with a better result for the client - and you (as team/vendor).

Adding it up
As you see from the above, not all of your status tracking may be directly connected 1:1 to items in your Project Plan WBS. Of course they relate to it, and impact it - but some types of information will not fit easily into common project management software tools for "rolling up" to higher levels. You still need to track it though.

You can also come up with other measures that you might want or need to track, so the above list is not necessarily "complete" for all projects.

And of course, the scale of your project factors into this too - there is a significant difference to the tracking performed on a 1 month project involving 3-5 people vs a multi-year, multi-department project involving a 30+ member project team. Generally the shorter the project, the less you need or want to track - otherwise you are doing more "overhead" than "doing the project". But in the larger projects, without the tracking and cross-checking measures in place, you will quickly lose control of the project.

In short, you should only track what you need, and no more - the critical bits you know you need to do as a responsible PM, and also enough information to satisfy the stakeholders, and to ensure a smooth flow of information.

3. How do we track it?

This is a tricky one. It is difficult to find any one system that will handle tracking the three information types in one place, or in relationship to each other. I have myself built various custom project tracking tools on larger projects to try to fill the gaps, by combining the WBS identifiers/names in a database with the CRAIDL, as an integrated cross-referenced solution. That definitely helped manage the project; the team leads all had access to the database from their own PCs. It worked very well for status reporting and meetings, and discussions where we could then identify the CRAIDL items assocated with a given WBS item, or the reverse - all WBS items impacted by a given risk. It was relatively sophisticated - it tracked status updates and effective dates as transactions for all activity related to the CRAIDL items in the database.

However, it did not have all of the "hard" data - parts of it were there, but the actual hours and financials were done separately.

And no, I'm not selling a system - it's not for sale - it was MS Access 2003 based, customized for the project, and did not scale well beyond the LAN. I just bring it up as an example of what can be done, and there may be value for you in doing something similar as well.

For the "hard data" there are a variety of collection methods:
- Hours expended [timesheets] - coded by task or task group
- Per-task updates in the WBS

You might have an integrated solution like Project Server that allows you to do all of your time entry and task level updates in one place - if so this is great; the fewer touch-points the better. 

If you just have a standalone tool like MS Project, definitely structure your plan so that it is simple for you to apply the status updates from your team - your own time is very important - you need to be running the project and communicating with the team, and spending "only just enough" time as is needed for your status reporting tasks. (Note that this part of your definied activities and should be in the communication plan - it only becomes "overhead" if you have to spend too much time doing it).

Tip: Whatever you do, design your measures/collection methods so that it is only input once. It definitely will be a chore if anyone has to put the same type of information in more than once.

The CRAIDL items can be tracked by spreadsheet, or put into a database. Or you may already have a system that will do this. I would recommend, however, that you try to track it in a database on larger projects - it will make the ongoing management easier, and more importantly, more visible. If you have the information quickly available when a risk event occurs, for example, and you know which items will or can be impacted, you are better able to respond.

The important thing is that you, as the PM, need to determine the best way for you to have the information collected, and that it comes to you in a usable form without too much manipulation. You will also want to ensure that form also lends itself to feeding "up" to the various stakeholders as well.

I made it a goal to be able to produce the various status reports in less than an hour a week; of course some automation helps (and I spent many "free time" hours building the system up front, but it did pay off as the project ran for more than 3 years). But even doing something as simple as providing a status reporting template to the team leads that they can easily fill in - and you can copy/paste into your master report - is a big step in the right direction.

These days, I am dealing with high-volume, shorter duration projects, and they have their own unique reporting needs. Again, I built a system - based on Sharepoint - to suit our specific needs; it does not have all of the CRAIDL elements this time, but it has been structured so that there are minimal touch-points for team members (less of a chore), and has a sophisitcated workflow engine to keep things running smoothly. It supports near-live status reporting, because team members updating status and hours are immediately available as they complete their tasks. It has also been structured to serve as the project system/business support stystem, and drives invoicing as well. Financial audit? Capacity Plan/Forecast? No problem - query to a spreadsheet and all of the detail is there for you to work with. 

Note: If you are interested in doing a system like this yourself, I have a free 9-part Sharepoint series on "Custom Project Systems on a Shoestring". Your specific needs will likely differ but the methods and principles will be the same.

What about the Project Plan?
At the beginning we mentioned there may be impacts on your project plan design, dependent on what you need to do for status reporting. This specifically applies more to the "hard data" measures, where you want to make sure that you can "roll up" the data to higher levels in a form that both makes sense to you, and to your sponsor/stakeholders.

There are many ways to build a project plan, all of them reasonable - but if you know how you are going to need to report status and progress, you will make different decisions on how you structure your WBS. 

- Will your top levels be functional areas?
- Will you have stages and then functional areas?

There will be further discussions on this topic in the next session - Project Planning 1.2: Building a Practical Project Plan.


 I hope you have found this session useful for your [upcoming] projects. As you can see it is difficult to describe a specific concrete solution that will satisfy everybody and all projects. But that, I think, is the point - on each project, you need to assess the lay of the land, and determine from the beginning what you will need to do for this particular project - and how much tracking will be needed. The goal is that fine balance of "just enough".

A final note - if you think that tracking some particular bit of information would be worthwhile because it "feels right" (or it kept you up at night thinking about it), even though can't see a direct reason right now - do consider including it. Your experienced gut may be telling you something. If you find later on that there are some things that need "less" tracking, you can taper their use off. But it is hard-to-impossible to go back and collect information after the fact - i.e. months later, if you did not do it in the first place.

And of course - think about who is going to be providing you all that information. Be wise in your requests on their time, and also make it visible how their information contributes to the overall health and success of the project.

So plan your tracking and measures, but be practical about it.

Good luck with your projects.

Project Planning Series
Previous article: Project Planning 1.0: The Importance of the Project Kickoff

Friday, April 20, 2012

Project Communications: GVSVCS (Free) Document Change Control System

[Also available as a Podcast]

Every project has documents. Dozens, hundreds, or even more. Some projects may be lucky enough to have an established document management system with version control. But many will not - and what do you do then? Or what if you do, but the client does not have access to the same system? Or you have a version control system - but people don't use it properly and you have a mess?

A very common scenario in the lifetime of any given document is that person (A)  writes a draft, sends it to B,C,D for review, receives feedback from each of them (separately or together), A updates it and the cycle continues until you have the finalized version. And quite often the files are exchanged by email.

Sounds simple, right? Well if you say yes - you have not actually dealt with the very real problem of version control (or change control). It is far too easy to lose updates when someone sends you a file that on the surface "looks like" the same one you had (same file name, mostly looks the same, you cannot see the changes because they were not marked or tracked properly etc). Or you overwrote B's updates with C's file when you saved the attachment. And even worse - if it is not being reviewed closely enough, that might not be caught until it is too late. Sound familiar?

There are many possible solutions to this of course - but I always like to think that simpler is better, because if you make it simple, people might actually use it. There are a lot of very expensive, fancy systems people just don't use - or don't use properly because they are difficult or tedious to work with.

Note that this is not a discussion on the "track changes" features of various document programs, which of course you should be using as well to track the internal updates. This is one level up from that, but just as important.

Introducing GVSVCS

Oh no, another acronym - and he must be selling something. No, it's just an acronym, coined by a customer staff person on one my earlier projects. Cheeky fella, but the name kind of stuck. And of course, GVSVCS is absolutely FREE. And it works on any platform.

GVSVCS stands for:

Gazza's Very Simple Version Control System. The beauty of this system that I still use and promote on projects every day is because it is simple, visible, and it works. It works for any situation where you have files and folders, in fact - not just documents. And it is easily adaptable to suit any project - anywhere.

GVSVCS is essentially a naming convention, applied and used by everyone on the team. Many of you may already have something similar, and if so - great! Keep on using it. But if you are struggling with lost documents and version control nightmares, please read on. And note that it is the spirit of the thing that matters - feel free to adapt this to suit your own project needs.

Under GVSVCS, every file has a consistent naming convention. Not overly restrictive mind you, just consistent. It goes something like this:

<descriptive part of the file name>_YYYY_MM_DD_[Vx.y]_INI_a.<Suffix>


My Project Plan_2012_04_13_v1.6_gmn_a.MPP

It's that simple.

Let's break it down.

<descriptive part of the file name> is the meaningful title of the file. It may even include your own standards for naming in this part. This could be something like "Project Plan", "Status report template", "Communcations report", "Deliverable XYZ package" etc.

YYYY_MM_DD - the last date the file was updated by the person editing it. So if they received it on March 2, 2012 and were editing it until March 18, 2012 - the file name that they will be sharing for review should have the date 2012_03_18, and not 2012_03_02.

We format our dates MM-DD-YYYY or DD-MM-YYYY. Why use YYYY_MM_DD? It sorts better when you are looking at the files in your folder. The front part of the file name should be the same all the time - so it is very easy to see what the latest version of the file is when you sort by file name. 

Why not use "document date" from the file itself? Well - if you ever opened a file and accidentally clicked SAVE without actually making any changes, you will have changed the internal file date. So don't trust it to see what your "latest" version is. This is a big problem when you are passing around multiple versions of the same file name. And if you are dealing with team members or clients in vastly different time zones, things can get a little wierd figuring out the file dates. And sometimes the date is modified when you saved the attachment from email. So again - don't trust that date for anything to do with proper version control.

[Vx.y] is the version number of the specific document. (This may be optional in some situations, like status reports). So if you are working on a new draft of a document, the number should be be incremented when you start applying edits from the last review session.

One convention we use on our projects is that drafts all start with 0.01, 0.02, 0.03 etc and the first issue (signed off version of the document/released deliverable to client) is 1.00. After that, 1.01, 1.02 etc. We only jump to 2.00 when there is a significant change, as in a major change request or architectural change. 

Why 1.00 and 1.01 instead of 1.0 and 1.1? The simple answer is that it sorts properly. And if you have 99 versions, you should really be on 2.00 by now anyway, or use a 1.000 system instead. But establish that from the beginning.

NOTE: You could choose to have [Vx.y] ahead of YYYY_MM_DD. It's your choice. But in my experience, versions happen sequentially anyway, so the date really takes precedence when you have multiple versions of V1.5. And also - if you are not following 1.00 version numbering but using 1.1-10, 1.11 etc, then you have the sorting problem all over again. So it is simpler and less error prone to have the YYYY_MM_DD part first.

INI - These are the initials of the last person who edited the file (i.e. you). You can't believe how much time can be saved by knowing who edited the document when you need to ask questions, because sometimes they may not have updated the change table - or the file type does not support internal version/author info.

a - It is a busy world and things move fast. And sometimes, you are working on an important document and want to save snapshots of your work, so you won't lose a huge amount of effort if you mess something up. the "a" represents a sequence, as in a,b,c,d...z. If you (or multiple people) edit the same document (or save snapshots) multiple times in a day, it can be very helpful to include the sequence. If you receive file on 2012_04_12_gmn_c.DOC, then you would copy/rename to 2012_04_12_YOU_d.DOC and start editing.

On very busy days where I want to preserve frequent snapshots of new work (tricky, hard to remember exactly what to do all over again if I lost part of it), I have got as far as m,n,o,p. And sometimes I have been working on sequence g and had to go back to e (not f) because instead of cut-and-paste I only "cut" at some point, but the stuff I had deleted was still in e. Save often, and save versions!

Of course you can cleanup and remove all the extra versions days later, but if and when you need them while you are working - you will have them. If you don't save versions - it may be a long night ahead.


For some types of files, you might apply some specific naming conventions to the first part of the name. These are of course are up to you - but here are some examples from recent projects I have worked on:

Deliverable packages:
Most of the time with these set deliverables we don't use the part in [brackets].

Requirements Documents:

Test Documents:

Note: We include <CustAbbr> because we are usually working with multiple clients and multiple projects at the same time. You may not need to do this.

Note these vary slightly from the "general rule" above, but if you agree on a standard and stick to it as a team for a given type of file, it tends to work well.

Extension - Folder Structures

Documents are one thing - but what about folders? I personally find it easier to find things when a simple, standard folder structure is setup. And when you have a mix of different related files that you want to keep together, where better than a standard-named sub-folder?

We frequently have several types of files we need to keep together - the versioned deliverable package, the test document, and often many sample files. Or versions of a draft specification and a number of supporting reference documents as inputs.

Again - you may already have your own well-defined system. But if you don't, here are some suggestions:

           Deliverable Name-#/
                       Test Results/

You may have many more levels and branches, but this is the general idea.

Of course, if you are tracking different things like status reports, it makes more sense to use a date as the grouping folder name (Year and month, or Year date month), i.e. YYYY_MM or YYYY_MM_DD.

Why 1.00 and YYYY_MM_DD for the folders? Same reason as the file names. It just sorts naturally, and will literally save you dozens or more hours during the project "trying to find that file", or making sure you are looking at the latest version.

Making it Stick

It is a short, small learning curve to use GVSVCS (or your own adaptation, call it what you like, if you actually call it anything). But people will still take a little time to get used to it. However, it is very important that you kindly but firmly make sure that it is being followed early on - so that it becomes an easy habit. If you let them go for a long time fixing their file names for them, they will not learn the habit and you will get increasingly frustrated. It works best when everyone is consistent. And it's not that complicated - so there is no real reason why they shouldn't do it!


GVSVCS is the system I live with and use every day - in my own PC file system, and on the shared document management systems we use to run projects. And the team members use it also - it simply becomes part of the communication culture. (And on projects I have managed, it is actually part of the Communication Plan as well). It is simple, and it works. If you build something difficult, people just won't use it.

And again, for those who do have wonderful version control systems - that's great, keep on using what works well for you.

But for the rest - be simple with your tools and processes, and be successful. 

Good luck with your projects, and managing all those documents!

Gary Nelson, PMP
Gazza Consulting Services

Wednesday, April 18, 2012

Project Planning 1.0: The Importance of the Project Kickoff

[Also available as a Podcast]

You cannot underestimate the importance of the Project Kickoff. It sets the tone for the rest of the project, and it is often the first time all of the key players on the Project will be face to face. In some cases, it may be the only time they all get together - so make it count!

It may also be the first time that you get to review the project objectives as a team, and it is where you will build the collective understanding of what you are trying to achieve - and the first stage in Project Team Development.

But what exactly is a Project Kickoff, and why do we really need it? In this session we will explore what it is - and why it is so important.

What is the Project Kickoff?

The Project Kickoff is not a party. Sure there will be some socializing, team members will be getting to know each other, all that - but it is actually an important key activity in every project.

At this point in time, you will have the project objectives, you (hopefully) have the budget, you have (also hopefully) a Project Sponsor, you have assigned team have a deadline, so ready, set - go!

Well, not quite. If you don't know where you are going, any road will take you there, and if your team does not know where you are going, they will travel as many different roads as you have team members. And nobody will end up in the same place.

You might even have a good starter project plan tucked away in your laptop - but it won't help you, unless you share it. And if you put that on the table right off, it can actually confuse things. So keep it handy, but out of the way for just a little bit.

Your goal, as Project Manager, is to make sure that everyone is travelling, more or less, in the same direction, and will all end up in the same place, at more or less the same time - with a successful project delivery. The Project Kickoff is a key tool (and sometimes a make-or-break activity) for delivering successful projects.

Every project, large or small, needs a Project Kickoff. But they can range in length from only an hour or two, to spanning multiple days depending on the size/scope of your project. If you have a small project (a few weeks, or maybe a month), a short meeting to get things pointed in the right direction (and have everyone agree on the direction and basic details) may suffice. For a complex, multi-year project, be prepared to invest some serious time up-front, clear your calendar and buckle in. You may find you need 4-5 days. On the type of projects I have worked with, this has been the norm.

In short, the Project Kickoff is where the rubber starts to hit the road - all the pieces come into play, and the Project Manager and Project Sponsor set everyone going in the right direction.

When you leave the Project Kickoff you will have many important things hashed out, the team will know who each other are and what role they all play - and you will also have an initial (draft) Project Plan. Perhaps even more than that - but let's start there.

Planning the Project Kickoff

Yes, you need to plan it. Running a Project Kickoff without any preparation can be problematic, even disastrous. The effects can range from loss of faith in the Project Manager ("if this is how they run a meeting, what is going to happen with the project?"), to the project rapidly getting off the rails - which can be difficult, expensive or sometimes impossible to recover from fully.

So take a few minutes (or hours) to plan it. Just as the Project itself has objectives, so does the Project Kickoff. And there are a few key deliverables that you should expect to walk away from the Project Kickoff with that will help you with the overall project. These are listed in point form, but expanded in the next section. Acronyms will be expanded, so bear with.

- Project Team (roles assigned & basic responsibilities known and understood)
- Clear understanding of the Project Objectives
- Stakeholder Map
- High Level Project Plan
- Skeleton Communication Plan
- Project reporting and recurring meeting schedule
- Sharing of any templates to be used on the project.

When you leave these will not all be in final, publishable form - but you will have a starting point for each, and in some cases quite fleshed-out lists, documents and spreadsheets.

Note: we will assume that you already have a Project Charter in place - the brief guiding document that has authorized your project to start. If you don't have one, you can include that as part of the Project Kickoff outputs as well.

10 Elements of a good Project Kickoff

1) Agenda, published in advance.

Yes, this is not really a deliverable - more of an input, but if you have a clear agenda the whole process will work more smoothly. You may also need to tweak the agenda as you go (multiple day event), so it is not just a static piece of paper.

The specific agenda you develop may include most or all of the items below, plus probably a technical overview, etc.

2) Project Team: Have all key people present.

This includes the Project Manager, the identified key (all team lead) project team members, Subject Matter Experts (SMEs) that will be involved in delivery or decision-making, key stakeholders - and the Project Sponsor. If you are missing key people at the beginning, bad things tend to happen.
- People "missed the message"
- People feel left out
- People do not feel they had input to the process, so may be resentful
- Team bonding gets delayed
- You start with an "us" vs "them" scenario - vs "we"
- People not initially present may not buy-in, or even actively obstruct the project later on

And remember - people may not know each other yet, so do introductions, and perhaps a short icebreaker. Get people talking to each other. Allow a bit of time for this before the meeting starts in earnest - and allow breaks where people can have some refreshments and continue to connect. Some of your team members may be "remote" after this, so spending some time getting to know each other helps ease any future communication issues when you are talking on the phone/email etc.

And on the Virtual note - if you do have anyone videoconferencing in, please pre-test the setup and check periodically during the meetings that they can see and be seen, hear and be heard. Phone-in is possible of course but video is probably better if you can manage it.

Enter the Monkey: An excellent facilitator we had on one project had a little "gimmick" that really worked - and grew a life of it's own during the project. He brought in a little stuffed toy monkey on the first morning and parked it on the table. Everyone looked at it, asked each other about it - nobody could figure it out - and then he told us what it was for. (It wasn't the icebreaker, at least, not intentionally).

The "Monkey" represents responsibility (as in "who has the monkey on their back"?) He used this device to help keep us focused as we did our planning - for any task, there can only be one "monkey" - one person (or team leader representing a group) responsible for delivering that item.

3) Break down the Key Project Objectives.

Use simple, clear words. You may have received a vision statement in management-ese about the objectives of the project from the organizational level, but it may be hard to translate that into something you can put your arms around. i.e. "Our goal is to have this project deliver a sustainable business support system to support operational outcomes and reduce costs." Say what? If nobody on the project understands what we are doing - and why we are doing it, they will not be fully engaged, and they will not buy into it (whatever "it" is).

Break the objectives down into simple, clear words. And really, the fewer the better. Not sure where to start breaking it down? Ask the Sponsor to explain what it is that they are really wanting to be achieved (this is a big reason they are there). Still not clear? Ask questions, have them provide examples, etc. Make it easy to grasp - so the team can buy into it. "i.e. Replace the servers and upgrade the software, which will reduce costs and reduce current user frustration." If you can put it on a bumper sticker, you are going in the right direction. Who knows? Your Communication Plan may include some publicity and catch-phrases that came out of the Project Kickoff.

Note that this is not the Project Plan - we are trying to set our GPS for the destination. We will figure out how to get there soon - but not just yet!

(Don't spend endless hours on this - set a time limit; the purpose is to ensure everyone understands the core project objectives. Shared vision generates emotion, emotion drives buy-in).

4) Identify the stakeholders.

Who are your project stakeholders? Think carefully now, and even a bit outside the box. Your stakeholders include the entire project team, the sponsors, the end users/customers/recipents of the result, and potentially many others that will touch on the project or its end result. The specific stakeholder map will vary from project to project - and may even include unexpected people outside of your organization or the customer's organization.

Identifying the stakeholders is a key step because it helps ground us and remind us "who we are doing this for", in addition to who makes decisions, who needs to be consulted, and of course who pays the bills.

Tip: You will want to use a spreadsheet for this - ideally a template.
You will also want to collect some basic information about those stakeholders - email, phone, address etc.

5) Build the CRAIDL. No, not Cradle. This is an acronym for:

These vehicles will become part of the ongoing life of the project, where key information is kept and maintained by the Project Manager/Project Coordinator and used on a regular basis by the team. (Note: If you are not going to use it, why collect it?)

Each of these items may have their own discussion session during the kickoff, or you may be completing these as you go during a brainstorming session. But the point is that more heads are better than one, and synergy develops when you work together. You are less likely to let important things fall through the cracks when you are collaborating and sharing.

Here are some brief descriptions of each item in the CRAIDL:

Constraints: It is a good idea to identify and write down any items that may limit the project, or limit future decisions, opportunities etc. Even if "everybody knows it" there is value in writing it down. Example constraints are budget, regulatory constraints, drop-dead key deadlines, etc.

Risks: Start setting up the risk log now. The group will be able to fairly quickly identify common and some unexpected risks (and opportunities - Positive Risk) that may impact the project. Risk management will be explored more fully in a later session.

Sidebar: What is a Risk? A key difference between Risks and Issues is that Risks have a probability. Issues are things that you have to deal with now - or you know you must address at a definite time. Risks are things that might occur, and will have an associated cost/impact (positive, or negative). A future realized Risk will be an Issue - if and when it happens.

Assumptions: Assumptions are just that - part of the "it's just how it works" from your culture, and there will also be assumptions about the delivery, execution and outcomes of the project that differ from stakeholder to stakeholder. Remember that these are not just your assumptions - these are team and known/anticipated stakeholder assumptions as well. But don't forget your own assumptions in favour of the team's - include yours as well, as you may have your own biases ("of course all of my projects are successful!")

Issues: As mentioned above - Issues are known items that you will have to address - they may be obstacles to navigate, problems to solve - or simply key things that will catch you up if you do not plan and take action to handle them.

Decisions: During your brainstormning, you will identify a number of items (few or many) that will require someone to make a decision - now, or at some point in the project. When a Decision item is added - it is important to identify who will need to make the decision (person or persons).

Lexicon: This one is optional for small teams and internal projects - but can be invaluable when your project involves Vendor and Customer. As you go through the Project Kickoff meeting(s), take note of jargon that people are using, and write it down, along with the meaning. The two groups may have very different "project language" and a key part of working together is to make sure you can communicate together. Sometimes there will be "new words" or acronyms, or there may be different understandings of the same terms. So make notes as you go - and review it at the end, and distribute it to the team. Add to it over time, as well.

Notes on brainstorming: Many ideas will come out that you may not be sure how to "label" right off. Don't worry about it - and don't stop moving - just record it on a Post-it, and park it. It will become clear as you work through the CRAIDL items where they belong - i.e. Aha! - that is an Issue, but this other needs to go to the Decision Log.

6) High Level Project Plan - Build it together. Use post-its!

It is time to start building up the high level elements of the project plan (the major moving parts and the major deliverables). Don't rush on and start up Microsoft Project just yet. This is still brainstorming time.

Note: You may be a highly experienced Project Manager, or relatively fresh - but please take this advice: If you already have a detailed Project Plan because "you know what needs to be done", don't throw it out on the table or on the screen. Tuck it away! You will have plenty of time to refine the details of the Project Plan once you finish the Kickoff. So hold onto "all of the details  that you know" - because, really - you don't. If you knew absolutely everything that needed to be done and how to do it, you wouldn't have a Project. You would have an assembly line.

You have assembled a team to help you deliver this project; it may be 3 people, 30 or 300. Every project is unique; it may be similar to others, but never the same. There are always wrinkles and twists - so hold back on being the "project expert" - and listen to the team as they work together. Your primary role (as a PM) in the Kickoff is as a Facilitator, or Coach. For now, everyone else is "the expert" - and you need their expertise plus your guidance and experience, working together, to deliver. You are certainly expected to know how to run the project, but at this stage - play the role of Coach/Facilitator, and draw out all of the important information you need for this project. Otherwise, they may not speak up at all.

Tip: It is important that, as the PM, you do have a grasp on all of the major elements required for the project. You can use those as starting points in the discussion. You may already have these prepared on Post-its, or have them written down and write them up as you go.

Ready? Set? Go! - Start with the major elements of the project, and start breaking them down into a semblance of a WBS, but with post-its. You may move them around a fair bit as you go. Take a photo and tidy it up in your favourite project planning tool after the meeting. (We will assume that you already know something about project planning, and how to setup a WBS structure. More on that in a separate session, but for now - "you are the expert" at this on your project.)

However, some guidelines - but first, a question.

Why go through this exercise of having all of the key people help flesh out the high level project plan, when you have most of it anyway? 
Answer: Because otherwise you will miss important things if you just try to do it on your own, and - a huge bonus - the TEAM built the plan. If you participate in building something, you have an investment, and you will buy in.

If you had just thrown up "the plan" on the screen, you would have people shutting down, not contributing, and not buying in. Then you have a long, long road of struggle ahead.

PM Tip: Guess who orders the Post-its? The PM (you). So most likely the plan will take shape mostly like you had envisioned it anyway - and you can help draw out any pieces you think might have been missed - but you will also be including all of the things that you would have missed yourself. A great starter of a plan - a team effort. Everyone will be tired at the end of the planning session - but they are much more likely to leave as a Team rather than Bob from Dept A, Sue from B, etc. They may even be smiling and buying you a drink. (Ok, maybe not, they may expect you to buy the first round, but at least they want you in the same pub!)

After that - once you have taken the photo of the postits, numbered/ordered and collected them, you can take them away and build up the details from there in your planning tool.

And of course - the project plan is not complete, you will have further sessions with smaller groups to refine the details. But you are off to a great start.

(Note: if you are running a smaller project, you will be trimming the above down quite a lot, maybe into an hour. And you may have a tight timeline, so you may already have the plan prepared. But still go in with the same "did I miss anything?" attitude - rather than "take it or leave it". So don't panic if you are on a smaller project - you can prepare a lot of the above yourself, and have the team help fill in any gaps, and then get rolling!)

7) RAM and RASCI

In step 4 we identified the Stakeholders, and in step 6 we developed the High Level Project plan. Now, we are going to look at what roles those stakeholders play, and include some clarifying notes in the context of the high level plan.

Introducing the RAM -  Responsibility Assignment Matrix

This may already be a well-used spreadsheet template from your toolbox, but it is a key tool to help identify who is doing what - and who is involved (in some way) with the various apects of the project. Now that you have the fledgeling Project Plan, and, having bought the first round and then studiously gone home to write up all thos post-it notes and WBS number them, it is time to put some teeth into it. Make some decisions, nominate the guilty and assign ownership to items.

The Responsibility Assignment Matrix is a way to map the Project Plan to people - and more than one person may have a role per item. Generally you will be mapping to the project plan (WBS# and title), but you may have some "external" items to track as well that do not (yet) fit into the project plan - i.e. the parking lot. You may wrap those into the plan later on.

You should end up with a spreasheet with the items (WBS#/title) as rows, and the key project members (team leads, SMEs, decision makers, key stakeholders) as columns.

And then what? You assign each row/column cell (as appropriate) a code. If they have no involvement in it, just leave it blank.

Assignment of Responsibility Codes: RASCI, which stands for
Responsible for Execution
Approver / Accountable
Support the Activity

Some guidelines:

a) Only ONE "Responsible" person or team per item (one job, one Monkey - see my article on Project Communications: Cutting through the Noise for more reasons for this). If you seem to need to have more than one "Responsible" person or team, then the item is too large and you need to break it down further. Think of it as the bottom level of the WBS - i.e. the Work Package. One package - one person or team. Or perhaps - you really mean that one team/person is the lead and another is a (S)upporter.

You still might still list the high-level items, such as the case where "John Smith" is the decision maker for anything in that branch. No point repeating it in every element unless it is truly needed for clarity.

b) Approver/Accountable person - this is a decision maker, the person who has the authority to make the decision and the accountability for the outcome. You can have more than one of these, but it is a good idea to mark the "key" person. One Monkey!

c) Supporter of the activity. You can have many people assigned here - so they have heads up that even if they do not need to deliver the item, they will be called on periodically for advice, help etc.

d) Consult the person on the item - this is for Subject Matter Experts (SMEs) that may not be decision makers or accountable for the overall item, but they do know their stuff, and like a farmer, is "out-standing in their field". You will end up asking these people lots of questions, so be careful not to burn them out.

e) Inform the person on the item (status/progress/issues) - some people just need to know what is going on, but do not need to take action, or "do" anything. These are the people you need to "CC" on anything related to that item.

8) Communication Plan

This is a good time to introduce the Communication Plan. You may only get started a little bit on developing it during the Kickoff, but it is important that everyone knows that there is one - and they may play a part in it. We won't go into the details of the communication plan here (that will be another session), but suffice it to say that you need to look at your Stakeholder list, internal and external, and discuss what types of communication will need to be sent to whom, by what methods, with what frequency and at which stages of the project. Not everyone needs to be communicated about everything all the time.

Tip: The RAM and RASCI chart will also factor into this. Part of your communication plan may be that any Team Member doing work on an item that has "A" or "I" people will always need to CC those persons on emails related to that item. As simple as that! ...And potentially as huge as a national multi-media presentation on live TV.

9) Project reporting and regular meetings established.

Before you close the meeting and send everyone back to their desks/office/other location, make sure that you have a few other items covered.

- Spend a little bit of time to go over any status reporting templates and documents the team will need to be using on a regular basis. Covering that now lets people ask questions and reduces confusion later on.
- Decide on the recurring meeting schedule. What meetings do you need to have as a team? How often? In person, by phone, online, or an alternating mix?
- Discuss the importance of each sub-team having its own regular meetings, to help catch things early etc.
- Share the contact list. Names, phone, email, etc. for everyone in the team. Make sure everyone knows how to get hold of each other.
- Share the initial RAM with everyone - make sure that everyone knows, at least at the high level, who is doing what - and who they need to go to for help, decisions and support. Who has the Monkey for that?
- Make sure enveryone knows how to get to the project documents/repository/etc.

Tip: Don't leave this session to last. People will be tired, ready to go "home" and no longer listening, because it is not as "engaging" as some of the other sessions. Do it the morning of the last day, or sometime in the schedule where people are still awake and not full of pasta.

10) Summary/Close

It will have been a busy few hours or days spent together. But don't forget to summarize the things you have done and built together in the Kickoff. It will remind them of how much has been accomplished - and re-affirm the joint vision and direction for the team.

And finally - review the Action Items from the Kickoff (with the Team), so that people know what they need to start addressing as soon as they depart/get back to their office.

Some additional Notes:

Key people/roles to include in the kickoff:
- Scribe. Have someone with quick ears/eyes and quicker fingers capture everything -all notes, all decisions, all key points from the discussion. Note that the Scribe is a dedicated function in this context - they are not expected to be involved in the conversation themselves, or they will stop listening/looking and will miss important elements. It goes without saying (well, let's just say it) that the Project Manager is never the Scribe in the Project Kickoff (unless it is the really short 1 hour version).
- Facilitator (usually the Project Manager, but possibly not, if you can get a professional facilitator, or someone very good at it. Do, however, make sure that the PM is putting all of the pieces of the High Level Plan post-its together, and not the Facilitator in this case)

Take Breaks!
- Schedule in regular breaks. You will be working hard, so give your body the rest it needs and have regular breaks. Have coffee/tea/water available, and snacks, lunch etc catered if that is an option. It is also a good opportunity for the team to begin to form and socialize. No alcohol until after hours though - and remember you need to be fresh to start again in the morning!

Keep them close
- Momentum is easy to lose. So if you go offsite for lunch, don't go far - and do it together. It is disruptive and stressful on the newly developing team to be waiting for someone to return who "just stepped back to the office for a minute".

Set the meeting ground rules
- Basic etiquette - cellphones, laptops, etc can be both tools and distractions (or escapes). Set up some ground rules at the outset - and they will form the "norm" for all project meetings that you have. So think carefully, choose wisely, and be firm about things that may detract from this and future meetings - even with the CEO.

Good luck with your project, and have a successful Project Kickoff!

Project Planning Series
Read the next article : Project Planning 1.1: Project Tracking - Plan it Now!

Gary Nelson, PMP
Gazza Consulting Services