We recently processed a change order to one of my projects. Like all of our projects, it’s a joint effort with the client – each organization has responsibility for certain deliverables. In this case, the original statement of work had the client developing all eleven of the integrations to other systems. These integrations are essentially files of change transactions, passed from the system of record to a destination; nine outbound and two inbound. This approach was identified as a risk to schedule up front, and sure enough, once we got started, they realized they couldn’t deliver in time. So they asked us to take over three of the outbound integrations. Not a change in scope, really; just a change in who would do the work, and a small one at that.
We have some standard guidelines for these sorts of integrations, since we do them all the time. Still, once I had an integration specialist assigned, I reviewed the tasks and estimated hours with him. We agreed that since two of the integrations were going to the same destination, we’d get some economies of scale in coordinating with the folks at the other end. We spent some time working the technical details in advance, because unlike our usual time and materials contracts, this one was fixed price. It had to be correct, or we’d eat the difference. I then wrote up the change order and sent it to the client, who ran it through their purchasing department.
Once approved, I called Howard, the integrations guy, and reviewed the project plan with him. We’re task-oriented, and most of us work on two to five projects at any given time. Consequently, when we have to deliver something can matter quite a lot. Howard would be able to work in the time slots needed, so we integrated his tasks in with the rest of the project. Outbound integrations have four basic testing tasks to accomplish:
- Unit testing, to ensure that the transaction file can be created in the correct format and with the “right” transactions.
- Connectivity testing, to ensure we can securely pass the file from the origin to the destination, and that they can read it on arrival.
- Routine operation testing, to ensure the system of record can originate and the end point can accept all change transactions for the time period since the last file was sent.
- A full replacement, where we send current state for all. This is only used in case the receiving end needs to recover from some disaster, but we still need to test for it.
Howard would do the development and unit testing independently, but for the other tasks, he needed to coordinate with the folks at the receiving end, and he needed some meaningful test transactions. So we scheduled his connectivity testing to end at the same time as the unit testing by the folks configuring the system of record, and the routine operation testing to occur at the end of positive system testing (“The Happy Path”). Then he’d run the full replacement at the end of negative system testing (“The Trail of Tears”), since all other functional and integration testing would be completed. Using these task dependencies allowed us to track any changes in dates without a great deal of fuss.
We’re having some internal discussions around change orders and how to track them in our time keeping system. I lean toward adding them to the existing project as a task, while some other folks want to set them up as separate projects. This is an important consideration for tracking financials and for contract administration. The logic of using a separate project is to allow invoices to be prepared against the change order, while the logic of setting them up as additional tasks is to simplify time keeping and administration for the folks on the project. In this case, since it’s a fixed-price contract, invoicing isn’t a consideration, since we’re invoicing based on milestone deliverables, so I’ll take the task approach. But I’ve used the project approach in the past, when it was appropriate.
The goal for managing change orders should be to minimize the impact to schedule and administration. In a case like this, where the reason for the change was to transfer risk, you want to avoid creating new risks. Obviously, Howard and I still have some work to do, but we’ve started this change off on the right foot.