Change Orders, a modification to the contract to reflect changes in scope or budget, can be uncomfortable for both the customer and a systems integrator. The nature of the engagement will drive how change orders are handled, but these are some of our collective learnings as described in Episode 6:  

• On a large project, it can be useful to exercise the first change order as soon as it is needed, to set the precedent that there is a contractual agreement in place and that material changes need to be memorialized. After that, we’re not big fans of doing frequent change orders for small changes. Project delivery is about the relationship, and the customer should not feel that they are being nickel and dimed.
• The Statement of Work should capture the original intent of what the customer wants to do with capacity. If what the customer wants to do changes or if the timeline changes, a change order is needed. If you are working within a capacity-based model, minor modifications to work shouldn’t warrant a full-blown change order.
• In the contract, be clear and detailed on assumptions. This will help set clear boundaries, giving the project team (and the customer) room to go back and have conversations as things change.
• Projects that are going to go off the rails, tend to do so early. People don’t want to admit it and by the time they become willing to talk about it, it tends to be a lot worse. It’s important to build a culture with the customer and with the project team that it’s preferable to discuss bad news early and openly.
• For projects that are in trouble, it’s important (but hard!) to establish a budget and milestone baseline that everyone can agree on. The mathematical formula is in theory easy:  comparing the average weekly burn rate to where you are with respect to duration and budget, plotted against the expected end date. Determining how much you’ve really done can be harder to determine.
• We build in extra coaching for teams when a project off the rails. While it’s important to provide top cover for your team and shield them from certain conversations and issues that can cause them to lose focus, the team on the ground is generally the most aware of issues. It’s important to address those things head on with the team.  Build in ample space to provide coaching, a safe space to vent, and for the team to be able to share challenges, frustration, and fears. This will take time, but once diffused, there is typically better focus on the go-forward plan. Remind the team to over-communicate during this period.
• In order not come across as a “Nervous Nelly” when discussing risks and issues with customers, it’s important to  have plan of attack before you go to customer. Their confidence in you will grow as they see that you’ve already thought through the issues and as they see that you trust them and the relationship enough to share it with them.
• We manage change orders differently in agile vs waterfall projects.  The definition that accompanies waterfall projects means that there is little room for adaptability and changes require contractual changes. In an agile or hybrid agile environment, there is more room for flexibility. At Appirio, we introduced concept of Exchange Order, which is another vehicle for change, without dollar impact, a vehicle which tends to be well received by the customer.
• The status report is an important communication vehicle. If used consistently and correctly, the status report becomes a living document, providing visibility into real issues and identifying a risk mitigation plan.