Tag Archives: fixed price projects

Fixed Price and Agility

I’ve come to love ‘agile’ systems implementation methods, and they are rightly fashionable in the nerdy circles in which I move.

But when I was trained on business software implementation methods many decades ago, I was told that it had to go like this:

  • find out what the customer wants, and write it all down,
  • get his sign-off on the requirements document,
  • design the system, and write it all down,
  • get his sign-off on the system specification,
  • build the system,
  • get his sign-off on the system,
  • and so on.

It didn’t work well. In the first step you might get it nearly 95% right, though there was still a danger that the customer didn’t know what he wanted until he’d seen what he might get.

But the second step was usually the dangerous one. If you’d gained the customer’s trust by the time you’d put the specification in front of him, he’d usually sign it off, even if he had no idea what it meant. System specifications are usually written in an inhuman language using the terminology of the target system. Crucially, they convey nothing at all about what it might be like actually to use a system.

The system build would often happen somewhere far away in a software laboratory, to which, of course, the customer would usually be denied access.

And then the last step didn’t happen, because when he saw what you’d built he wasn’t usually very happy.

agilecascade

This was the old-fashioned ‘cascade’ method and it’s rightly out of fashion. The ‘agile’ method involves more frequent meetings, discussions and demonstrations, so that the customer sees what you’ve understood, what you’ve designed, and what you’ve built and can quickly tell you if you’ve got it wrong before it’s too expensive to change course. When you’re implementing highly configurable software systems such as our time@work, expense@work or forms@work products, or Infor’s SunSystems, prototyping is relatively easy and this method is perfect.

At systems@work we’re doing a big implementation project for a fund services provider. It involves expenses, vendor invoice management, billing, timesheets and lots of workflow and reporting, and all the accounting that goes with all the transactions that are implied. Yesterday we conducted an important  prototyping session, and I’m happy to say that it went well. There are a few things that we must change, but there are no fundamental misunderstandings.

But what about the agile method when a project is a fixed price one? Isn’t it potentially a recipe for disaster, in that changes of course are unpredictable and there’s no single moment when you can pin down the project scope in a system specification and treat all subsequent changes as separately chargeable?

This is not an easy question to answer. Wise and experienced project managers will build in a large ‘contingency’ component and perhaps put more emphasis on getting the requirements document right (even this stage of the project can involve proof-of-concept prototype demonstrations). But if you allow changes at later stages it’s hard to charge extra for them.

There is no perfect method. I would only say that if you believe the old ‘cascade’ method is a better one for large fixed price projects you are probably deluding yourself. You may be able more easily to define what’s out of scope, but it will be no easier to obtain the customer’s agreement that he should pay for all the ‘mistakes’ and scope creep, whether they are demonstrably his fault or yours.

 

 

Keeping an Eye on Projects

Share

Whether you’re a lawyer, an IT consultant, an engineer, or working in PR, architecture, or for an advertising agency, or indeed any other kind of professional service organisation, it is your time that is probably the chief determinant of project cost, and the fees that your firm will charge to your customers. Sometimes it’s a matter of adding up all the time you’ve reported in your timesheet and multiplying it by a fee rate; sometimes your firm will have estimated how much time is needed for a project and calculated a fixed price for a well-scoped piece of work. In both cases, it’s never quite as simple as you would wish it to be. Sometimes there’s time you can’t charge, and very often a fixed-price project takes more time (and very occasionally less time) than planned.

If you’re working for a professional services company and you’re in a position of responsibility you’ll be familiar with these month-end questions:

‘How much of your Work in Progress (the time you haven’t yet billed) will you be able to bill? How much is it really worth?’

‘How is your fixed price project going? Do you expect it to take more time or less time than planned? ‘

You’re asked these questions especially sternly by your firm’s Finance Director, since he or she is responsible for calculating revenue for the month that’s closing, and revenue depends on the value of the project time that you’ve reported for the month. This is not just a matter of multiplying time by fee rate.

At year-end it’s even more important, since it’s your annual P&L that statutory and corporate auditors will analyse, and if you’re not too careful your managers will defer serious consideration of the value of Work in Progress and the progress of Fixed Price Projects until then. That can mean unpleasant surprises in the last month of the year.

At LLP Group we use systems@work’s time@work to keep an eye on what’s going on. Adjustments to Work in Progress value and the value of time in Fixed Price Projects are tracked as discounts or uplifts to the values that are calculated from timesheets. We can track how these values are discounted or uplifted when billed or written off, and we can track when this is done.

It’s never pleasant to discount work, but it’s some consolation when it’s done steadily throughout the year, rather than all in the last month. Take this report, for example:

project virtue

This, from one division of the company, shows the month in which work was executed down the left y-axis and the month in which the  value of time was increased or decreased along the top x-axis. What we see is that the value of time is written up or written down in the month in which it is recorded, or a month or two later. This is virtuous. This division doesn’t execute many fixed price projects and doesn’t hold Work in Progress for long.

lessvirtuousThe matrix, above, shows data for another division, one which executes more fixed price projects. It’s clear that decisions about the write down or write up of time are made sometimes many months after time is recorded, and as year-end approaches large values are written off. This is less virtuous.

If you’re running a professional services organisation this is the kind of tool you need if you want to avert unwelcome surprises.

When it comes to Fixed Price Projects you might also track the estimates that your project managers give you and track time recorded on the project (green), planned time (blue), and evolving estimated time (orange).

In this case, below, the project manager has seriously underestimated the number of days’ consulting that the project requires. As the project progresses he or she estimates more and more work. The result is that the achieved project rate is nearly 40% lower than the planned rate of 500. It’s probably loss making.

FPP

In the more complex case, below, the project has been ‘sold’ on the basis of ‘planned’ time, and as the project progresses the client adds additional scope and additional planned time (though not at the same fee rate). Time estimated by the project manager for the whole project gradually exceeds planned time. The Rates graph shows how the planned daily rate for the project is reduced as the scope of the project increases, and the actual achieved daily rate also declines.

FPP changing project

Whatever kind of service you’re selling, it’s essential that you keep track of the value of Work in Progress and the progress of Fixed Price Projects every month of the year.

FPPs – You Need ‘Commercial’ Project Management

Share

Project management skills are in short supply. Good project managers are rare, but you need to find the best of the best if you’re to make Fixed Price Projects (FPPs) successful. It’s not just a matter of getting things done on time, but of getting things done profitably for you, and to your customer’s satisfaction.

Although project management is often regarded as a specific skill, my own preference is that a project manager should have a good understanding of technical aspects of the project. Without this it is difficult for him or her to judge the plausibility of estimates, solutions and excuses.

project management

Good Commercial Project Management means:

  • Delivering the project at a level of quality that meets the client’s reasonable expectations
  • Delivering the project on time, assuming that the client has met his obligations in terms of timings, and assuming that the project manager has accepted the project plan
  • Delivering the project within estimated consulting and development days, assuming that the project manager has accepted the estimate
  • Ensuring that staff are motivated to deliver on time and estimate
  • Ensuring that the project meets its profit targets
  • Ensuring that the scope of the project is, at all times, well-defined and that all out-of-scope work is charged (usually through separately contracted Change Request Forms/Orders)
  • Ensuring that staff document their activities well enough to support all out-of-scope work if it happens either ‘accidentally’ or is agreed
  • Managing client expectations to ensure they are reasonable

When passing a project from the sales phase to the delivery phase it may be wise to document the salesman’s understanding of the client’s expectations. Does the client expect perfection? Is he willing to compromise? Is he reasonable? We might call this an ‘expectations audit’.

Collectively, when starting the delivery of a project, you must be able to answer these questions:

  • Does the client understand that a fixed price project is limited to a defined scope?
  • Does the client understand that estimates must be based on documented assumptions, specifications, and descriptions, and that if they are not, areas of imprecision must be highly constrained in terms of requirements (for example, if reports are not clearly defined)?
  • Does the client understand that it is we who can say whether a requirement is clearly stated or not
  • Does the client understand that out-of-scope work must be separately specified using a Change Request Form and that he will be charged?
  • Does the client understand that if we carry out extra work due to the mistakes of his staff or due to delays for which his staff are responsible, then he will be charged for this time?
  • Does the client understand that our fees are reasonable?
  • Does the client accept that compromise will sometimes be pragmatic if he is to obtain benefit from the project?
  • Does the client understand that his staff must be motivated, and encouraged, and must behave reasonably and cooperatively?
  • Does the client understand that software development is difficult?
  • Does the client understand that software quality is rarely perfect?

If the answer to many of these questions is ‘No’ then the salesman hasn’t done a good job, and a question arises as to whether the project is worth the risk. If it is, then all involved, and principally the project manager, must continue to move the client’s expectations towards the ‘optimal’ ones.

If a project manager is to manage a project well, he must keep in close contact with consultants and developers who are involved more deeply in the detail of the project, and must be alert to out-of-scope tendencies. It is also essential that time spent on the project be captured at task level so that comparisons with estimates (assuming, as one should, that estimates are drawn up at task level) can alert the project manager to commercially dangerous situations as early as possible.

If all of these and other issues have gone through your mind when considering, scoping, selling, planning and contracting a fixed price project, then you might just do it well.

See also:

FPP – A Frightening Acronym

FPP – Estimating Fixed Price Projects

FPPs – Mitigating Some of the Risks

FPPs – More Pitfalls to Avoid

FPPs – Yet More Thoughts on What Could Go Wrong

FPPs – Getting Paid and Getting Out

Summary

  • Ensure that client expectations are reasonable and that the client understands the implications and risks of a fixed price project from both his and our perspective
  • Ensure that scoping is as precise as possible and well documented
  • Ensure that initial estimates are based on well stated assumptions and are agreed by sales and consulting staff
  • Try to persuade the client to engage in a first clarification and design phase that is jointly funded and which will deliver more precise scope and estimates
  • Make sure that the contract protects you from the unknown unknowns, and that nothing is open ended
  • Make sure that staff are motivated to deliver on time and within estimate
  • Monitor task actuals continuously during project execution
  • Make sure that payments cannot be unreasonably withheld

 

FPP – Estimating Fixed Price Projects

Share

I posted a blog a few days ago on Fixed Price Projects (FPP – A Frightening Acronym). FPPs frighten me because part of LLP Group (a part I’m happy to have sold) worked with the wonderfully open-ended Microsoft Dynamics business software products. We sold, scoped, estimated, and executed such projects poorly, to the extent that we made no margin at all, sometimes on hundreds of days of consulting, even whilst satisfying our customers. Our consultants and developers were no doubt excellent, but our sales processes and project management skills were insufficiently sophisticated and cautious.

Because of this I’m wary of FPPs, even if I know that they can be done well, can be controlled and can be profitable. To that end, I try to make sure that everyone in the company is aware of the risks and how they might be mitigated.

My last notes were about the Sales process. Here are some thoughts about Estimating.

estimating

Estimating

Estimating is a process that must involve both the sales and the consulting/development team.

It’s a time-consuming business. But FPPs get off to a bad start if we calculate estimates poorly on the basis of incompletely understood requirements, and half-baked solutions. Even ten free days up front might save hundreds of days later.

Of course, it’s the sales team that has to sell the project and who, in conjunction with management, must decide on price (for a defined scope), but our sales and management team MUST listen to what the consultants have to say. If they say they must know more about the client’s requirements, then the sales team must provide them with more. Never be tempted to think ‘Well, if I add another five days or so, that’s bound to be enough’. It isn’t.

And ALWAYS add contingency to your estimate. (And then more.)

In the end it is a commercial issue as to whether you knowingly ‘sell’ fewer days than you know that you need to execute the project. Whether that is commercially wise or foolish has nothing at all to do with the deadly sin of starting a project with inaccurate estimates of how much time the project will actually take you.

What if your estimate is insanely too low, and you discover that once you’ve started the project?

Well, it’s important when creating an estimate to make your assumptions explicit. This isn’t a slippery way of avoiding commitment, a trick that you’re playing on the customer. No, it’s an honest statement of the basis for your estimate. If it turns out that there are material facts that you’re unaware of, then you’ll be glad to be able to go back to the customer and ask for more time. And make sure that you make it clear that it isn’t your fault that you didn’t ask. You need to include a statement like this one in your proposal:

‘This estimate is based on materials provided by the customer and discussions with [named individuals]. Whilst we have built a certain level of contingency into our estimates to deal with the unexpected, the following assumptions are material, in that if they are incorrect our estimates may be materially wrong in either direction. These assumptions are [examples]:

  • In valuing your inventory you use only one method of valuation, weighted average valuation in local currency in conformity with statutory tax regulations
  • In valuing your inventory you value it only in one currency
  • You have no need for lot tracking of purchased, intermediate or final products
  • Etc’

 

And very importantly…

  • Your staff are motivated and committed to the process of implementation and will provide timely support as required
  • Your staff will be available for the time that we have estimated is required of them’

 

If possible you should build the estimation process as a first step of the project itself, or present this as a project stage where estimates and assumptions are confirmed. If necessary, give some free days to this, since your risk is greatly reduced by it, and you have a chance to demonstrate competence.

But if you do this it is also important that you build into your contracts an escape clause.so that both parties can terminate the contract or renegotiate it if the estimates or assumptions turn out to be incorrect.