Big Dreams are not to Overshadow Reality: Project Benchmarks vs. Project Baselines

When managing projects, we are obviously trying to do our level best to do a perfect job. However, in our quest for perfection, it is important not to get carried away by ‘’dizziness with potential success’’ and to ensure that dreaming big does not stand on way of achieving the core deliverables required. It is important to understand the difference between the benchmarks and the baselines that we need to consider. Benchmarks are usually defined as ‘’best practices’’ that can be achieved within industry/organisation or (on a smaller scale) with a particular business or technical process. On the other hand, baselines are commonly referred to as minimal standards to be accomplished in order for projects ‘’not to fail’’. So in other words, while benchmarks are near-ideal, baselines are also recognized as ‘’fit for purpose’’ and can satisfy the organisations’ requirements.

While doing consulting work, I realized that some of the Australian and international companies do not tend to differentiate between benchmarks and baselines very clearly.  It can lead to a range of potential problems. The most critical of these problems are discussed below:

1.      Taking Benchmarks for Baselines

This may initially appear to be a ‘’blessing’’ rather than a problem. After all, wouldn’t it be great to match the best practice and complete projects with flying colours? Unfortunately, while chasing benchmarks, companies also need to acknowledge that excellence comes at a cost!

While talking to clients to finalize project requirements, I’ve always tried to gain understanding not only of what the deliverables need to be but also the exact purpose of these deliverables. Technology implementation (particularly for top notch technologies) is always a very costly process, so before we implement a state-of-art technology, we better be sure that it is not only going to ‘’look good’’ but the investment of financial and human resources into the implementation is well-justified. Sometimes, the tasks that the company needs the technology for are rather trivial so instead of super-technologies that are recognized as benchmarks, cheaper and simpler solutions could be available at fraction of the cost. For example, implementing highly complex (and expensive!) customized solutions could be a good idea for large corporations, but for smaller organisations – not only the cost of achieving the benchmarks may prove to be excessive but also the practical benefits are not going to be significant enough to justify this expenditure. At the same time, by implementing a standard package (aka reaching the baseline) – the specific processes and tasks that the organisation is aiming to achieve may be fulfilled comfortably enough.

It should be noted that I am not trying to play down the importance of reaching ‘’the best practice’’. However, given how stretched organisations are usually for resources – it is worthwhile to acknowledge the limitations as well as not to aim at excelling in processes where the ‘’excellence’’ is not required!

2.      Failure to incorporate requirements for Baselines for ALL of the Project Deliverables into the Contracts

At the time of PI (Project Initiation) stage of the project life-cycle, ‘’Thinking big’’ is natural. So when discussing the newly-conceived project proposal, the focus tends to be on the key deliverables rather than specific tasks and functions that are parts of those deliverables. Unfortunately, it is the inability to complete these ‘’little tasks’’ successfully that can drive the entire projects towards failure. Given that in the modern day and age, many of the IT projects are outsourced to the 3d party providers, probability of potential failures to have all of the baselines accomplished is greater than ever. Non-IT organisations struggle to monitor work-in-progress on the projects that they outsource consistently enough – particularly if the projects are large and need to be delivered over a significant time frame. Furthermore, if the baselines are not identified in the contract/project documentation – one can be never sure that 3d party will have eye for detail and will follow all the requirements religiously as needed to reach each and every one of these baselines. Last but not least, if the outsourced project/task is completed below the vendor’s expectations, it may be difficult to get the provider to acknowledge the shortcomings unless the baselines are documented in fine print.

3. Baselines are easier to measure and define

In every industry, there are both benchmarks and baselines that have been established over time and both get corrected/updated as the time goes by. As far as reliability is concerned, baselines appear to be more reliable and accurate. The reason is that they are based on achieving core project/process objectives that are essential for functionality. While benchmarks are often referred to as ‘’industry standards’’ – it is actually the baselines that represent the standards best! The concept of ‘’best practice’’ could sometimes be very subjective and not reflective of the every-changing reality. This is particular evident with IT projects that focus on service delivery. Service delivery standards are accurate and easy to follow when they focus on baselines but whenever the service delivery benchmarks are being discussed, interpretations often tend to vary.

To sum up, projects are successful when all of the deliverables are accomplished successfully. If some of the deliverables are fulfilled to an outstanding standard – it is a truly great achievement and should only be welcomed but it is essential to make sure that excellence with some of the deliverables does not come at the expense of others failing to meet the respective baselines!

Dr Michael Baron is the Founder and Managing Director of Baron Consulting - one of Australia's leading Business Consulting, Recruitment & Training Agencies. BC consulting, recruitment and training services are currently available in Australia (Melbourne and Sydney), China, Singapore and New Zealand. He is also lecturing MBA and MIS students at some of the leading Australian Universities.