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.