Avoiding the great "CON" in Projects aka "Scope Creep"

I recently heard from a few friends about not so nice things happening in their projects.

One friend even when to the extent of classifying consultants as "ConSulThank" saying first they Con you then they Insult you and then Thank you after billing you coming up with the acronym "ConSulThank".

Two buddies who are heads of HR and IT in their respective MNCs over coffee shared about their frustrations in their HRMS project implementations.

Some horror stories can be easily avoided.

1. Starting with internal requirements

Any HRMS project or any IT driven project or any project for that matter is driven by a need. The needs and wants must be properly documented. Pain points faced and inefficiencies to be addressed must be identified as much as possible.

A mature organisation may find it easier to identify the gaps, but this may not be the case given the quick moves and rapid changes in people, process, and systems now.

Firstly, we need to stop and ask the big question of the inner why. Why is the project being embarked on? What are my organisation's needs and what are my needs as a stakeholder and a person who is going to engage with the project?

An experienced subject matter expert and consultant working hand in hand with the internal organisation experts may help to document the internal requirements properly and thoroughly.

If existing systems are used, we need to identify the special customisations and configurations we have done to ensure that while new improvements are being documented, we do not forget and forgo what is working well for us currently.

2. The Request for Proposal (RFP).

Some companies use a RFI (Request for Information) and then move to the RFP stage. Most of the time, RFPs are in the form of a simple excel template that documents and asks vendors to respond about features of systems. The more detailed the RFP, the better the evaluation.

This is a chicken and egg situation; we would not want to expose our inner workings and configurations to the entire system vendor community via an RFP. However, we should nevertheless prepare the scenarios and our business rules that need to be tested as part of the selection and committal process from the vendors.

I have seen cases where vendors have marked all areas in an RFP as being fully compliant just to score higher technical evaluation points even though the features requested are not there in their product. We need to be incredibly careful in our evaluation here.

3. The Proposal

The proposal when received will normally contain technical as well as commercial areas. We need to be mindful that the RFP compliance and requirements are responded to by the vendors. The more detailed the explanation, the greater the confidence we would feel from the vendors.

4. Statement of Work (SOW)

I have seen a proposal that excludes the statement of work while some others include this. This is a particularly important document. It allows the vendors to assume the implementation work that they will be doing and allows us to gauge the expertise and maturity of the vendor in stating their basis of work estimates.

An easy example would be the number of pay elements, the number of bank files, recruitment processes, onboarding initiatives, performance forms etc. they will configure. With this submission, the organisation can then ask for addition or reduction of the scope of work from the onset based on their organisation's needs.

One word of caution here. We need to gauge what the customers mean by the scope of work against what we understand from it. E.g. If we have 3 companies and each has a standard 3 types of performance forms being one for Individual Contributer, One for People Manager and one for Senior Management, we may assume that it is a 3 form setup. Some systems go by global setup i.e. treats it as 3 forms while other systems go by form per company and the creation of 3 forms by 3 companies would mean 9 forms. This needs to be clarified from the onset during the clarification stage of the project.

The SOW should be added as an addendum to the contract to cover all aspects. If possible, an NDA should be signed at this stage and some form of detailed clarification given the unique scenarios of the organisation needs to be incorporated into the SOW and contract of the implementation service.

5.Business Requirement Document (BRD)

Here is when things really get interesting. The contract is signed, and sales and pre-sales passes the buck to the professional services and implementation team.

In most organisations the actual doers and users of the system may only get involved in the requirements study stage of the project. This is a gross mistake. The actual ones using the system should be involved from the onset of the project and be involved in the selection as they who are the transactional users may be able to identify gaps better. In the meantime, the people manager and the senior management can gauge not only the transactional and operational efficiencies needed but also the overall strategic, tactical, and reporting requirements needed.

In the business requirements stage, the implementers from the vendors and the key users will sit down and look afresh at their requirements. Most organisations make a great mistake about forgetting about their RFPs at this stage and vendors will happily use the business requirements document as a basis of their scope of work.

The contract, the RFP, the SOW is completely ignored sometimes to the detriment of the organisation and sometimes the vendor.

The completed signed off document now becomes the scope of implementation. Smart vendors will gauge the documents against the SOW and if needed request for change orders for additional scope of work based on the requirements study.

This now creates a key genesis of frustration and tension between vendor and organisations. Organisations will be cracking their heads into how they are going to request for additional budget for changes (if a buffer budget was not anticipated) while they may compromise on their requirements since the work is now out of scope.

The compromise may lead into greater and longer-term frustrations. I have seen the lack of certain automation from the beginning contributing to good people leaving organisations too due to this unhappiness.

It is better to be prepared with a budget buffer and to scope as much as possible during the earlier stages of the project to avoid these pitfalls.

6.Variation Order (VO)

Finally comes the worst effect of scope creep which is a variation order. Call it what you will, a deviation order, change order or variation is not good news for the organisation.

There is a difference between a planned VO vs a premeditated VO. Sometimes a honestly unplanned VO which has been resulted due to the lack of scope planning can be ill conceived as being where the vendor is taking advantage of the organisation. There are vendors too for the sake of getting a project undercharge their scope of work with the hope of moving into profitability with their VOs.

If a VO improves on a base product and extends the functionality and automation of the original scope of work, then it is good. However, if it is due to unanticipated scope creep whereby requirements were not put into paper properly and extensively during the earlier project stages then it is awfully bad.

What may happen is that the original scope of work or expected desirable outcome of the project i.e. The inner why is now only achieved through the VOs.

From the chart above we can see that the scope is achieved via the investment of more time, cost and emotions via VOs.

There is a way to avoid scope creeps which some people call "CONS". We just need to be more thorough in our preparation and our requirements.

It does not hurt to have an experienced HRMS Consultant like me on board to assist too :)