I have an application, it is either already in production or soon will be. I need to develop a contract to take care of it and maintain it over time. Based on what I posted before a strong argument can be made to go Time and Materials with that because it is very hard to predict how much maintenance work will actually be required. I could have a lot of new functional requirements. I could have a lot of patches and service packs that need to be applied. I might need to make periodic changes to the data in the database without making an functional change. Finally I could discover new classes of vulnerabilities that we were not aware of at the time of deployment. All of these changes will need to be included in the application during maintance and I cannot predict with any certainty how much effort will be required to implement these changes.
That is a strong argument for a T&M contract. However I think we can accomplish this with a Fixed Price contract. Here's how.
Let's first look at the functional changes. These often represent the lion's share of the changes to an application. The business needs a new report. The formula for this data element needs to be adjusted. Those types of changes are business-related functional changes. The problem that we experience today in managing these changes is that we pick an arbitrary release date and then work with the business to decide which requirements are going to be included in that release. What does the business do? They try to get all requirements included in that release. The business has a hard time seeing beyond the release that is coming up next. We in IT might have a plan, we might even share it with them but the business only sees the next milestone. As a result they work to have their needs met with each release. They try to get all of their requirements included in the release. We in IT often let them do it because we must support the customer. This causes a problem. Inevitiably some of their changes (requirements) are more mature than others. Some changes (requirements) require more work in terms of analysis and design than others. And that is the key to making this work fixed in price versus T&M.
Only mature requirements that can be accurately predicted in terms of development can be included in the release. This would normally cause consternation for the business because, as I mentioned earlier, they can't normally see beyond the release that is right in front of them. That is why we need to get all releases on a calendar schedule. They need to essentially be commoditized. Let's use a scenario like, release dates are Feb. 1, May 1, Aug. 1, Nov. 1. This helps us to reduce the impact of traditional holidays. Now, back up from each of these release dates and give me two weeks for User Acceptance Testing (UAT), and give me two weeks of chill time after a release. This means that we can start working on the Feb. 1 release on about Nov. 15 and we must be done by about Jan 15. That leaves eight weeks from mid Nov. through mid Jan. to do all the work necessary for implementing the release. Let's be fair and give two of those weeks to the contractor as requirements time and internal QA time. That leaves us with 6 weeks of actual development time. Thus I am left to price the release based on how many developers I expect to be available. At 6 weeks for a 40 hour work week I am looking at 240 development hours. Add more Dev people I can increase in increments of 240. For my purposes here, and because it is maintenance, not new development, I'm going to try to get by with just one developer and push that risk to the vendor. At $125 an hour that is $30,000 right there. Add in costs for a little BA, documentation and internal testing and you are looking at the neighborhood of $50,000 per release.
In order to balance the risk with the vendor we need to cap their risk at 240 development hours. As such if we try to pile on requirements we will need to prioritize the requirements and get down to the maximum of 240 development hours. We may have releases that are under that threshhold but we can't go over that number. This is actually a benefit on the vendor's side because if they are good about anticipating our needs then they will even out the level of effort for the year and remove the peaks and valleys.
Then when we Project Managers work with the business we need to help them to understand that we will program mature requirements for the next release. Requirements that are not fully cooked will be programmed for the next release, provided they are mature by February 15. This approach makes the business a partner in the process. The pressure of trying to get everything into a particular release will be diminished because the following release is only 3 months away. Heck that might not even be enough time to get mature with the emerging requirement.
The non-business parts of the maintenance must also be accounted for. In this scenario I have patches and service packs as well as security vulnerabilities. I'm going to come out and say that service packs are not minor. Service packs would be targeted to one of the four quarterly releases. Patches and minor upgrades will be included in the quarterly releases as a matter of course, but we may need these small changes to be implemented with a faster turnaround. Changes required by US Cert often cannot wait. To address this, we will need 4 fixed price items to accommodate configuration changes, patches and security adjustments. I will also need the option of an additional 4 with another additional 4 after that. This would allow me to implement security adjustments in a timely manner each month if I need to. I bet that I will need at least 4 of these over the course of a year and I know I won't need more than 12. I would price these changes at $1000 to $1200 a piece. These should be fairly easy to implement (if you have a good CM process in place) and should not require a high calibure of technical resource to do it well.
The production database change requests (PDCRs) should also be in the $1000 to $1200 range. I would buy 4 of these over the course of the year and I would program them to fall right between two separate releases, Mar. 15, Jun 15, Sep. 15 and Dec. 15. Remember major release also include PDCRs, but sometimes we may need these on a more frequent basis, like right before the end of the Federal Fiscal Year and right before the end of the calendar year.
Thus in summary, for the FFP contract I have 3 classes of deliverables:
- Functional Release $50,000 (NTE 240 development hours), qty 4, delivered on Feb. 1, May 1, Aug. 1, Nov. 1
- PDCRs $1000 qty 4, delivered on Mar. 15, Jun 15, Sep. 15 and Dec. 15
- Configuration/Security adjustments $1000, qty. 4 with two separate options of 4 on these per year, delivery TBD.
Hope this helps.
No comments:
Post a Comment