All too often organisations selling IT solutions ignore the role of project management up until the deal is done and the project is starting. In fact, up until it is too late. Organisation are focused on selling products and licences and ignoring – because it is complex and outside the confort zone of sales department – the integration complexity that would need the inputs of a project manager. Project management is expensive and the pre-sales budget is often not big enough to support this cost.

Amongst the impact of this non-involvement are:

• Missing or wrongly evaluated integration activities
• Incorrect dependencies between activities
• Little (if none) check on resources availability
• Missed scope
• Very difficult start of the project – as the knowledge transfer is delayed until the contract is signed
• Bad customer satisfaction
• Incorrect project budget…very likely overspending

This results in a project that starts on the wrong foot and very often means that the delivery will not match the success criteria established. I always suggest an earlier involvement from project management and a better connection between pre-sales and operations processes.

1. Earlier involvement from Project Management

With a PM embarked in the pre-sales activities (read: not full time, just “as needed”, meaning if the opportunity has been qualified as “complex” and requiring the inputs of a PM) the integration requirements will be reviewed by an subject matter expert, this will ensure that the scope of the integration work is analysed correctly giving the benefits of better work packages estimation, better resources needs estimation, better scheduling. This will massively de-risk the project.

2. Better connection between pre-sales and operations processes

Both do not have to be completly separated. During pre-sales some project work can already be started for example to clarify / validate technical aspects, validate project planning. This is ignored more often than one could think! You’d be surprised. At least the pre-sales should generate the following:

• First version of the Project management plan. Describing milestones up the end of the project (those things are contractual) and detailed planning for the first phases of the project (requirements / design for example), describing the complete set of deliverables, assumptions, constraints and dependencies. The rule here is to use a standard project management plan and decide which section should be described during pre-sales. For example if the human resources skills needed is going to be an issue then it should be explored in more details at this stage.
• Acceptance plan and criteria. They are usually contractual items – so all inputs should already be there
• High-level design of the solution: to remove misunderstanding, validate some design options…it is in fact the result of the engagement of the technical department on the project. It’s good at this stage. This is best done when there an agreed interaction between pre-sales and operational processes. When the flow from one to an other is natural and agreed. This way the same language is used and both departments (sales, operations) AND the customer will be better off.

As part of my current assignment I have to manage a number of tests activities involving several testers in several locations, testing several physical environments. To add to the complexity each environment goes through 3 distincts tests phases and we are delivering several sub-systems – each of them with specific tests and testers assigned.

Due to the complexity it rapidly turned out that a simple excel spreadsheet to manage the list of issues arising during testing was not going to be enough. The major issue was to manage concurrent updates to a single spreadsheet. Multiplying spreadsheet was not going to facilitate communication either.

Here comes in Redmine: an open source “issue tracking” system (it does more that just that but that’s the main feature) developed with the Ruby on Rails framework.

I am not using all Redmine’s features as I only concentrate on tracking issues and Redmine is very good at it, here is why:

• the user interface is simple and make good use of Ajax technology to simplify some interactions. This means creating or updating issues is easy to get processed. I added 10+ people on Redmine and nobody experienced problems with it or needed particular “training” to use the tool.

• there is a possibility to define custom fields for issues. Now that’s a killer feature as I needed to categorise bugs per environment, test phase and even “Lot” : pieces of the solution jigsaw. Custom fields are nicely integrated and esy to define. The database implementation for them will surely damage the performance when big volumes are involved but that’s the price to pay. It is also possible to filter the list of issues displayed, even filtering on customised fields. Very handy. Those filters can even be saved for later used.

• the export function (to excel) does the job perfectly – although the various updates to the issue (to record progress on day to day basis) does not appear in Excel export. This is a minor issue. I use excel export to generate pivot tables for reporting on number of issues.

• the rights management is fairly advanced and very customisable, it is good to give appropriate rights to group of people.

• It is stable, has relatively no bugs (so far) and the community is fairly big, ensuring support and enhancements. As of July 2008 there is very regular upgrades and you can suggest enhancements, the community is very responsive.

• one can create additional list of bugs or “things” with bespoke fields if needed. It is therefore ready for multiple deployment within or not within the same project. Careful: this is databaseCPU hungry.

I have been using this product for more than a month and it never failed me in any case. So I am a fan. I haven’t however looked at the other features such as News, Wiki, Repository…there is also a feature to track effort spent and progress. However it is fairly “basic” and will not suit my project’s size.

So if you are looking for a generic “tracking” tool then Redmine might be for you.

I have been recently re-reading the excellent book from Stephen Covey, 7 Habits of Highly Effective Peopleand, stumbling upon the definition of a habit, I made the link to human resources and to a wider extend organisation in the context of project management.

Take a look at what’s a habit according to S. Covey, a habit consists of three things:

• Knowledge: what to do
• Skills: how to do
• Desire: want to do

These three components are fundamental to keep in mind at many stages of project management and must not be forgotten for – I am taking here references to the PMBOK:

• Acquire project team, because your team will need to have a balance of those three components. It is important to have people (some if not most of your project team) with the right motivation (desire), you will need to make sure people have the skills required to deliver the project scope. I am taking the knowledge here is a pre-requisite but it is to the PM to bring them to the knowledge of what needs to be done
• Most planning activities in Project Time Management ( Resource estimating, Duration estimating), because you will need to know what mix of the three components you have in order to perform those planning tasks accurately
• Risk management: ensure that you analyse the risks based on the resources mix you have in your team
• Develop and Manage project team, as you will have tailor the development of your staff based on the components mix
• Obviously resources constraints are very often on top of the problems list of project managers. This is a further reason why taking a good look at the definition of a habit is even more important as the human resources inputs to your project becomes a critical success factor, in other words, it must be right if you want your project to succeed

I once managed a project where all “installation engineers” where new to the company and their skills did not yet reach the desired level. On top of that because of many changes within the organisation they were not particularly motivated, the results is:

• What to do: OK, covered
• How to do: Not really as their skills did not match what was required of such resources
• Want to do: Not really as the motivation was not there – so to create it I adjusted their roles on the project to better meet their career goal

Principles should guides one’s life, that’ the message from the 7 Habits of Highly Effective People, it is a good message to remember at every stage of a project.