I have documented my feelings on Fixed Price vs. Time & Materials contracts in a previous post. Based on that I bet that when we think about the work associated with the maintenance of an application or system you would probably think that I would be in favor of T&M components. Actually I can see the argument there but the reason for this post is to push the other way. Let's walk through the scenario.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.
The government is raising the bar. Contractors beware, the government is doing a much better job of inspecting IT deliverables. I had a situation this week in which I asked the Information Security Office of my agency to perform penetration testing on a release. The Information System Security Project Manager (ISSPM) was able to take control of the application and could have seized the system.
Many agencies have established policies concerning secure code. It is only a matter of time before there is a law on the books mandating that policy across the sector. When I describe this type of policy I think it is congruent with the Section 508 policy (from the Americans with Disabilities Act). When thinking about 508, if a contractor delivers an IT product that is not 508 compliant, the government does not have to pay for the product, or if the government has already paid for it, it is made 508 compliant at the cost of the contractor.
Similarly, if a contractor delivers an IT product that has vulnerabilities that allow a hacker to take control of the application then the government should either not pay for that deliverable, or if it has already been paid for, it should be remediated to not have that vulnerability at the cost of the contractor.
Two years ago this was probably just as much of a problem as it is today. The only difference is that the government generally lacked the technical sophistication to verify the security of the delivered product. But now, thanks to an investment in training and several strong industry tools the government now has the capability to verify.
I know that there are significant vulnerabilities out there. Trust me when I tell you, it will be cheaper in the long run to adopt best practices and keep your developers honest. The types of vulnerabilities I am seeing are from poor development practices and lazy developers who don't clean up their code. The government now has the capability to see these weaknesses and when they are identified they reflect poorly on you as a company.
No, it is not the title of a new (or old) Disney film. It is a software product that I received a couple weeks ago that helps you to make lightweight videos like what you see on Youtube. I love it. Quite simply, it is going to change everything. Training; do we ever really have a budget for training? With Camtasia, who cares? You don't need a training budget, just a half day. I am able to put a quality video together in just a few minutes. It is especially good for the type of training I need to deploy; here is a new system, now use it. Reviewing and testing functionality is now simple because I can create a video of the functionality under review and the team can watch it to gain familiarity with the software even before they start testing. Also, some of the people on my team don't know how to use Sharepoint. Because making a video is so easy, I spent about 10 minutes and made a Windows Media Player video that showed them how to save, check out, load back in and check back in files. But Shhhh! Don't tell them. They think that I worked really hard to develop it. Now I have been making training videos for quite a while. PowerPoint has a lot of capabilities built right into it. But the files can get really big, and it doesn't handle video very well. Flash is a great tool, but you need to be a developer to master the interface. All I want to do is meet the pressing need of the day. Camtasia has native plug-ins for PowerPoint and allows you to import right in. It also has this feature called "Smart Focus" which is cool because it allows you to have a fairly low resultution video that zooms in to specific areas of content. It literally zooms in on your mouse or cursor when you let it hover for a moment or start typing. Finally you can edit video and audio separately to make tweaks and adjustments. LOVE LOVE LOVE.
At the risk of sounding completely nerdy, I was very pleased to have met Jeanne Ross, co-author of the book, Enterprise Architecture as Strategy. Everyone gives Zachman a lot of credit and deservedly so. But it is Jeanne who answered the question, "So what?" Her book told us why we should care about Enterprise Architecture. From the first pages you start to understand the concepts of the "Core Diagram" and the type of operating model your business either is, or strives to be. Then you leverage this information to focus on projects that help to realize the core diagram. Periodically come back and revise the diagram and stive to keep projects and activities consistent. In my current job, this is one thing that is gaining traction, but I had to plant these seeds a long time ago. The core diagram should be something that everyone in the organization recognizes as obvious. As such I began to talk about things like how specific commodities are at the center of everything we do. That notion was picked up by other people and now there is a common understanding about the commodities at the center of everything we do as an agency. The next aspect I hope to introduce is that organizations, specifically state agencies, Indian Tribal Organizations and local agencies are another core component. This is essentially our CRM content. This type of change doesn't happen over night. This is a long and gradual road, but not painful. People already know and understand these concepts. If they challenge you on them, then the architect better really think about it. There is no square peg - round hole situation here. This understanding must be immediately obvious to everyone who has visibility across the organization. Thanks Jeanne and keep up the good work!!!
So I really enjoy training and instruction. This week I got a good week in. I think that the Wednesday content was the best. It was all about Service Oriented Architecture (SOA). It has been a buzzword for several years now, but can you really describe what it is. I could in a theoretical sense before this week, but I think I can in a technical sense now. SOA is not a thing, it is a it is a development strategy. You don't wake up one day and discover that you have developed a SOA. Instead what you do is you make a commitment that you are going to look at processes and the systems that deliver those processes in the abstract. They cease to be systems and instead become a collections of components or services. Generally there are three ways in which services are achieved. The first and most simple is to share a common database. This has risk though in in terms of load and functionality. It also may have problems concerning timing. The second Web Service we looked at was the point to point web service. It is good and I understand it but I didn't see how is was different from what came before in APIs for traditional applications. I have since done a little research to contrast the two and now I know that APIs are usually more language-dependent. Thus if you have a C# application the API is expecting to respond to C# requests. The web service makes an API more generic so that it can accept and respond to a greater variety of requests. Point to point services are great, but what happens over time? The number of points and connections between them become a maintenance burden all by themselves. The web services are supposed to decrease maintenance but if alloowed to grow in this organic manner they represent an ever increasing burden. That is why the third area of SOA is really gaining popularity. I hate to try to oversimplify it but the Enterprise Service Bus seems to me to be like the routers and switches that allow your network to work. Think about it, what does a switch do? It receives messages and routs them in the right direction. ESBs do that too. They receive the calls to web services and get them to where they need to go. In this sense the ESB is like the phone book (directory) of web services for the organization. Additionally the ESB can help you to understand the dependence you have on external web services as well. It is only with this level of visibility that we will be able to implement governance with teeth. The reason I say this is because I could have service A, and someone unknown to me could create service B which is exactly like service A. Assuming that the same service is provided by two different applications my ability to discover this service and force convergence of these two is less likely without an ESB. Anyway, good stuff I really enjoyed it.
