Project Management – Can You Handle the Truth?

August 30, 2010 | Author: PM Hut | Filed under: Contract Administration & Close-out,Procurement Management,Procurement Plannning,Project Management Musings

Project Management – Can You Handle the Truth?
By Michael Gorman

Quite apart from your usual day-to-day operations, a project is mandated when a business need requires your organisation to meet new and unprecedented objectives. This could be the need to distribute your enterprise geographically, to manage your documents and records more accountably, or to accomplish a fundamental change in the way your organisation does business through new utilisation of new technologies or improved business processes.

The skills and resources required to meet these needs, or implement the necessary changes, may simply lie outside your organisation’s operational capability. Or your strategic plan may require your departments to keep their focus on their primary business functions whilst your organisation moves through change. In either case, you may decide to outsource and publish a request for tender in the hope that a self-managed external group can make a competitive proposal and accomplish a satisfactory solution in an acceptable time frame.

At least that’s the way we imagine it should work. But more often than not projects outsourced in this way are plagued with low quality results that are delivered late and with blown out budgets.

What goes wrong?

I have been involved in project work – on both the client and vendor sides – for over twenty years, and have seen the same pattern played out more than once. A fixed price contract frequently goes to the lowest bidder who (intentionally or otherwise) underestimates the scope of work required. By the time the client discovers this fact, the amount of time and money already expended mean it is already too late to go back and examine the more realistic alternate proposals. For the same reasons – time and money – the client is also averse to seeking legal remedies to enforce the vendor contract because, at the end of the day, neither of these alternatives give the client what they now desperately need.

This unfortunate state of affairs generally creates a disappointing outcome. The vendor faces high turnover as his staff burns out from facing the client’s set expectations and demands. The client’s staff, equipped with inadequate and inappropriate systems handed-off by the vendor, are now set up for failure in their operational tasks, becoming jaded and disgruntled. Both client and vendor tend to lose their best and brightest in the process. Only those who settle for something less than excellence remain slogging it out in an environment that has only become degraded despite the efforts and expense. A project initiated with the noble objectives has achieved its opposite.

Is this sounding familiar?

But there is no need for such unsatisfying outcomes. I have also seen projects where outcomes met and exceeded the objectives, where clients and vendors endeavoured for excellence and achieved it together. But these projects were different – from the beginning…

The following questions, answered in the paragraphs below, explain this difference.

What is Project Management?

Project management is everything done, from ‘before the start’ to ‘after the end,’ to ensure a successful outcome.

Who is the Project Manager?

In today’s business environment, the vendor often provides a ‘project manager’ to manage the staff the vendor assigns to the project. This person may coordinate vendor activities for several projects concurrently, as is often the case with vendor-side ‘project management.’

However, the interests of the vendor-side ‘project manager’ can never be closely aligned with those of the paying customer client. The vendor-side ‘project manager’ is put in the place of ‘serving two masters’ – the customer/sponsor and the vendor account manager. This clear conflict of interest will always be decided in favour of the vendor and will generally fail the client.

Alternatively, if your organisation is in the vanguard of enterprises that have thoroughly ‘projectised’ their organisations, you may employ your own dedicated project manager to protect your organisation’s interests in managing the project.

However, if your organisation is more functionally oriented, and has focused on building up its operational expertise and knowledge intrinsic to the business and not in the underlying tools and techniques necessary to deliver needed solutions, then you may not have the most relevant and dedicated project management resources at your ready disposal.

When does the Project Manager become involved?

In common practice today a contract is established between the contract management office of the client organisation and the sales team of the vendor. A project manager is not assigned until late in the process, after a contract has been signed. This often happens before the vendor – or even the client – is familiar with the detailed requirements or knows clearly what the contracted deliverables are meant to be! As discussed above, this ‘short-cut’ to execution allows the vendor to be ‘intentionally ignorant’ and underestimate the scope of the work in order to bid low. It also allows the client (temporarily) two self-deceptive presumptions:

  1. That the stakeholders can postpone, or entirely avoid, taking the time away from their operational work in order to be interviewed and assist in drafting and review of a clear statement of work that will address their full range of expectations and requirements.
  2. That time and money can be saved by assuming that the requirements are all obvious and implicit; the solution vendor will automatically understand the client’s business fully and knows what they want; and the vendor can simply get on with execution immediately without going through ‘the formalities.’

These two presumptions are likely to be very costly to the client and frequently are enough on their own to cause a project to fail.

Capturing the complete range of requirements before engaging the vendor is the most certain way to ensure that engagement is successful for the client. This is particularly imperative when the vendor will be engaged through a fixed price contract. The important work of capturing requirements can only be accomplished with the close cooperation of this organisation’s stakeholders early in the process.

If you feel that your business is easy to follow, that a vendor is certain to immediately understand it completely, then there is nothing unique and unprecedented about your ‘project’ at all. The odds are good you will be able to find an off-the-shelf solution that satisfies your needs without having to initiate a project to provide one.

However, if you find that the solutions available ‘out of the box’ are missing something important, one must question why off the shelf solutions have not met such an obvious requirement to satisfy this as a common need. Obviously the packaged solution providers were missing insight into your kind of business. Your vendors will miss it too unless your organisation provides it in a clear and unambiguous way. The only question is will you provide it early on or incur the exponentially increasing cost of providing it later?

When the project manager is a late comer to the project, only entering after the contractual obligations have apparently been settled, he or she will frequently find themselves already committed to incomplete, self-contradictory requirements and unrealistic expectations which could easily have been prevented had his/her early involvement been considered. Unrealistic and self-contradictory projects lead to early breakdown in project team moral and inhibit their commitment to achieving the project’s goals. Without involving the project manager from the beginning in the completion of requirements and contracts, the project manager inherits the near-impossible task of managing a project for which there is neither adequate planning nor metrics. There can be no success measured because there is no means of measuring it! Proceeding in such an unconsidered way robs the client of meaningful results and deprives the team of an opportunity to apply their best efforts in obtaining clearly defined objectives.

When do the Vendors become involved?

Vendors, necessarily, are only selected after the Project Manager completes the first iteration of project planning.

Engaging the vendor before detailed functional requirements are documented, and before the authorised project manager has compiled a detailed statement of their work, let alone an articulated work breakdown structure (WBS), violates one of the cardinal rules of project management. Such a practice loses the certain advantage gained when completed requirements are carefully incorporated into the vendor contract (part-in-parcel) with the assistance of a Project Manager involved from the beginning. Only the Project Manager, who has full familiarity with the stakeholder expectations, can guarantee that contracted services will provide quality solutions that satisfy the objectives. Such a Project Manager participates in vendor contract management from the earliest stages of procurement through the closing of all vendor contracts involved with the project.

How should the vendors be contracted? (What kind of contract?)

More often than not, the client assumes they will get the best value for money by imposing a fixed-price (fixed bid) contract on the vendor. Some of the less fortunate consequences of fixed price contracts have already been discussed above.

It is understandable how budgetary constraints make this type of arrangement superficially attractive to the client who must budget on an annual basis for all their needs. Many public-sector clients are actually required by law to tender in this way and have no other option.

For clients with options, other alternatives should be considered prior to the procurement process. Vendors can be constructively engaged in using cost plus award and incentive when project requirements are difficult to completely specify or when the customer reserves the right to frequently change or add to the scope of deliverables during execution.

Another benefit of completing the Work Breakdown Structure and schedule before procurement is that contracts – whether ‘fixed price’ or ‘cost plus’ – can award partial payment to the vendor upon customer acceptance of key milestone deliverables. This type of planning reduces risk to the client and provides a great deal of incentive to the vendor.

What prevents a contract from going wrong? – (Arbitration and legal measures)

If a vendor is in breach of a contract it is the duty of the project manager to formally notify the vendor promptly of the breach. This provides your organisation with the paper trail your solicitors will need to enforce the contract or find a cure for any breach.

But without the will to seek recourse through legal means, an organisation outsourcing solutions leaves itself to the tender mercies of vendors whose interests are best served by moving on to new projects which promise the influx of new money.

The hardest part is always finishing the job.

Michael Gorman is currently a Project Management Consultant at Project Studio Consulting. He has Twenty one years experience consulting with project teams in the IT, Software Development, and Engineering/ Manufacturing industries. You can read more from Michael on his blog.

1 person has left a comment

Great article! I am comming across of these problems everyday. I wish this article I was read by the contractor as well as by contractee.

Tomas Bartek wrote on September 2, 2010 - 5:09 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories