Over the years, I have worked on a number of fixed price technology projects where there has been a direct impact to my ability to meet deadlines due to delayed dependency deliverables from my Customer.
This could take place at a number of project stages, such as delays in reviewing or signing off documents, or more frequently when too much time is taken to UAT delivered code. In most cases I have to scramble to reassign resources or do battle to convince the Customer that these delays are essentiall change requests on top of the current FP scope (seldom easily done !) While I can inlude a statement in my PID to highlight this risk, it can be very difficult to define all scenarios where dependency slippage can take place, and even more difficult to convince a customer that a specific occurance was covered by the PID.
Can anyone help with advice on how I can implement a risk management process that will help me avoid burning days on Fixed Price contracts that are "not my fault" ?
I recommend that you place these deliverables in your contract. If you do not have the specifics at the time of contract signing, then you should have a secction within that contract that covers that risk. Most template contracts have the stock wording. Saving Changes...
Elizabeth HarrinDirector| RebelsGuideToPM.comLondon, England, United Kingdom
Do you do risk reviews with the customer? It is worth making sure that they fully appreciate the impact to the project from delay on their side. Alternatively, write something into the contract that says both sides will review documents etc within x days. Make it a two-way thing, so they don't think you are singling them out! Saving Changes...
Although I know it is a tough sell, I wholeheartedly support the concept of client penalties. If you, as the provider, are late in delivering the key deliverables highlighted in the contract, you're expected to pay penalties, right? Well, fairness dictates that it should be a two-way thing: if the client is late in giving you the material that you absolutely need to work with (which should be contractually defined), then they pay you x % of your daily rate per day of delay.
If you're going to work together, it's only natural to share the risks, too. Saving Changes...
Hans RobbersSenior Director| SalesforceVlissingen, Netherlands
Great question Ken.
My normal approach is to include the customer dependencies in the plan and discuss them on a weekly basis. Create awareness.
As soon as it slips I present in my weekly report the slippage of that week and the accumulated slippage. Each week I request a cr and if it is not granted by the customer I escalate to the steering committee first and secondly internal in the it department or my own own organisation to look for a solution.
In the contract or project charter I include response times for review/approvals and for answering questions. After the period deliverables are deemed accepted and subject to change control.
For questions I add to each question an assumption which the team thinks is the way forward. After the response period this assumption becomes the truth and again subject to change control.
hopes this helps Hans Saving Changes...
Wai Mun KooPMO Director| Intergraph PP&MSingapore, Singapore
Good question and a tough one indeed. I believe most of us have encountered similar situations before. What Julien and Hans have suggested make sense. The challenge is how to establish the mutual agreements to share the risks with the customer in a win-win situation. As Ken has pointed out, this is not easy and it depends on both the soft skill of the project manager and the type of customer that we get. Laying down the terms and clauses is one thing, having the customer to agree and acknowledge them later is a totally different game. Perhaps instead of putting them as 'penalties' (sounds negative), we could try to allocate a sum of money aside. If the customer are able to deliver all their deliverables on time, then they will get a discount out of the total cost of the project as a reward (sounds positive). You can use the sum of money allocated earlier to offset this discount given to the customer. With the discount as a pretext, you may actually motivate the customer to pay more attention on being on time with the deliverables. Saving Changes...
Apologies for late response....for some reason I havent received a notification when your posts were added to my question.
Some great advice and a definite helping hand - thanks. As has been pointed out, a lot depends on the Customer, the PM to PM relationship, and how slippage has been tracked and communicated. Avoiding surprise is a key tactic to ensuring commercial impact from slippage. Planning is paramount and factoring slippage control into our base documents we have a reference for 'when things go bad'.
Saving Changes...
Wayne MackRetired| RetiredSouth Riding, Va, United States
Two recommendations. One specify acceptance criteria for all deliverables. Two, if the customer is late, shift resources to another effort. When the customer meets his milestone, let him new the new dates caused by his delay. Note, if the contracted company does not have other billable work while waiting on customer responses, that is not the fault of the contractor company. If one has only one outstanding project, ensure costs are set to cover downtime. One can always give a rebate if the contracting organization is on time or early with its deliverables. Saving Changes...
Darren KosaPlanning & Controls ContractorHampshire, United Kingdom
Hi Ken,
Some good suggestions given in the previous replies to your post. Coming at your problem from a slightly different angle, how effectively do you manage the scope of your project and then communicate delivery dates to your client?
I'm not casting aspersions on you abilities as a PM, however, in my experience both sides of the project - the delivery team as well as the client - are sometimes so focussed on their own agenda, that they occasionally lose sight of the bigger picture.
As you’re tendering for a fixed-price contract, one of the first things I would do is accept that change is inevitable and conduct a risk assessment with your client prior to kick-off. Weigh up a number of factors (maturity of technology, time constraints, etc.) and get them to set aside a pot of money from which you can draw down when the usual changes start to materialise.
Work with your clients. Make them aware that as a PM you fully expect them not to know exactly what they want right from the get go. Gently remind them that any changes requested earlier in the development lifecycle, will cost them less than changes requested later in the lifecycle.
Use a WBS as a communication tool. Anything that doesn’t appear on the WBS is not in scope for the project. A WBS doesn’t go down to task level so it’s a useful tool to capture and cement yours and your clients’ vision for the project.
Picking up on communications, are you also giving your clients enough notice of impending deliveries? It’s very easy to complete a deliverable, present it to your client, and then fully expect them to be able to sign-off/approve the deliverable when you’ve only given them a weeks notice.
Sometimes it will take the client a little bit of time to ensure the right people are in place, to either review the deliverable, or get a team to undertake UAT. The more notice you give them, then hopefully you are reducing the likelihood that there will be a delay attributable to your client.
Wayne also makes a good point in his reply. Do you document the acceptance criteria for each deliverable? Acceptance criteria in the form of a checklist might mean that you can stagger the sign-off process so it isn’t a ‘Big Bang’ exercise at the end of a piece of work - more of a rubber stamp.
Done correctly this should reduce the overhead for your client. They will have had more exposure to the deliverable during development, and it should therefore take less time for approval at the end.
Does your client have the necessary technical expertise to sign-off on a deliverable? It may be that they don’t, or the resource they had identified goes will not be available for some reason. You could mitigate the risk by sourcing appropriately skilled resources on their behalf.
You could also look at your own delivery schedule. Are you expecting your clients to review and sign-off 20 deliverables one month and then nothing for the next two months? It may be that you have sufficient float that you can stagger your own delivery rather than over burden your clients.
As a last resort you could always sub-contract the work out. You’ll still be on the hook for overall delivery, but the day-to-day problems will be somebody else’s responsibility to manage.
It’s always easy to lay blame on your clients and forget you are supposed to be delivering benefits on their behalf. Anything that you can do to pre-empt that should pay dividends in the long run.
Regards,
Darren Kosa Saving Changes...
Jon ToothillClient Services Director| Lightbox LearningStockport, United Kingdom
Hi Ken, It is a good question and one that I'm sure almost all of us will have to deal with at some point in our PM careers.
For me, this starts right up front in establishing a partnership with the customer to deliver the project together. If they are providing deliverables or reviewing documents or code, then they have a commitment to delivery just as we have - our challenge is getting them to understand and accept that.
At the risk of stating the obvious... this can start simple, agreeing that if a client deliverable, say content for web pages they are supplying, is late by 5 days then that flows straight through the plan to a 5 day delay to our deliverable. From there agree turn-around times for reviews and for UAT and most importantly agree when these are and the resource we expect the customer to make available for these to happen. In my experience if we are showing early the commitment necessarily and the impact it will have, the client will endeavor to line up the people and hold up their side of the bargain - it is when we spring a deliverable / UAT on them that they may not be able to review to the timescale we expect.
There is also the question of what to review - depending on the project and client, do they know what you want them to review and how to go about it? For some they may be very willing to help but need guidance, there is every chance you are involved because they need specialist advice. A point made already in agreeing acceptance criteria.
On the flipside of this, we now absolutely have to meet the agreed dates, if client has a review panel set-up for a date they are going to be less than happy if we don''t meet this - maybe incurring cost at their side, certainly inconvenience.
So in summary, build a relationship with client, share impact and effect early and encourage open communication on both sides to share delays or challenges as early as possible...
...and when that doesn't work its late nights and firefighting I'm afraid
Jon Saving Changes...
Massimo D'UlisseProject Manager Professional (PMI)| Brightstar 20:20 Mobile UKManchester, United Kingdom
Hi Ken,
There are a number of strategies I use to address your very valid point.
1) During the project planning phase, I explain that a late signing-off a document, or a failure to provide e.g. access to the customer's VPN have an immediate effect on the project schedule, thus it is in the customer's interest to agree on some rules in order to make the schedule plan realistic.
2) We agree on the standard duration of the reviews and response time to questions
3) Once agreed on them, we present that in the kick-off meeting as one of the key success criteria for the project (and of course I insert that into the plan).
4) For dependencies, I put all of them in a section of my project plan and use a MS Project flag to mark them as such (with a special symbol to distinguish them from normal deadlines) - and every week I extract and put them on a slide in the project status report that I share weekly with my counterpart. It's kind of "heads up" for what the customer is bound to provide in the next weeks, so that the PM has time to start moving things internally in order to meet the dependencies on time.
5) Also, it is very effective to show, in the dependencies slide, the planned vs. the actual date of fulfillment of the dependencies. It is a fair, objective reporting of how the project is going. This way the customer can see where he performed well and where he was late. I use also to add some comments to the dependencies explaining what is the effect on the plan if they are missed.
6) I present delays as much as possible in a objective way during the steering group meetings, explaining where they are coming from - sometimes they are caused by my team, sometimes by the customer. Showing that in some cases you were late makes your report sound objective - a report where only the customer is on the wrong side might be questioned as biased.
7) As other colleagues suggested, we should always expect some delays to happen (risks!), you should always have some contingency to absorb some days of delays. Plan for the worst, hope for the best.
If this is a fixed price project, you don't need to tell the customer how much money you have set aside for contingency.
Having buffers avoids also that a single day of delay has to be notified and justified to the steering group, and a change to the plan presented and approved.
8) if the customer constantly misses their deadlines, then this has to be reported and discussed as an issue with your counterpart and with the steering group, in a constructive manner. No finger pointing, but just making everybody aware that all the delays are piling up and putting the final deadline at stake.
Engaging the customer in such discussion makes the customer feel part of the solution, so they will normally be eager to cooperate. In the end, if they have internal problems (e.g. resources overallocated), they only can resolve the problem and help you to keep the project on track.
