Tuesday, May 26, 2009

The Clean Break

We develop systems and applications and we typically use contractors to help us reach deployment. But once we see that checkered flag (thank you Indy 500) how can we transition from development into maintenance. As I consider this question there are two things that I consider, risk and cost.

Let's look at cost first. When comparing development to maintenance, there is high liklihood that the objective will not be achieved in development work (see the Chaos Report) while getting there in maintenace mode is often much easier. Usually development work is more time consuming and difficult when compared to maintenance work. As such, I believe that maintenance work should cost less than development work. But then if it should cost less, it is really hard to switch gears with the development contractor and get lower rates.

This is where risk kicks in. We could get lower rates if we competitively sourced the work to maintain the system or application. But if we did that, someone who isn't the development contractor might win, and that holds greater risk.

Do you see the problem? We developed a system or application with ABC, Inc. and they charged us $200 an hour. Now my system is finished and I need to make modest changes over time to maintain it and to continue to deliver business value. But I don't want to pay $200 an hour, but at the same time, I don't want someone that isn't ABC, Inc. to maintain it. What is the solution?

The solution is that you must trust yourself. When you developed the project, did you do the right things? Did you receive GOOD documentation? Did you have the uncompiled code checked into a code repository? Did you have someone verify that is has been check in? Do you have an installation and configuration guide? Do you know how the development team developed it? If you can answer yes to these questions then you should feel comfortable making a clean break and competing the work to maintain the application on the open market. This competition should drive the price down. Hopefully the development team will compete, but because you have done the right things, you should have confidence that you will get good maintenance service at a lower price regardless of who is performing the work.

Alternatively, if you didn't do the things you needed to do; the documentation isn't good, the source code is just the compiled version, etc. you might be stuck. You can't get away from the development team if you don't have the documentation. If another team can't come in and pick it up then you will have problems trying to transition. I see this type of thing happening all the time. It is really frustrating for me.

Don't sacrafice your documentation. Make sure you are in a position where you can make that clean break when your project transitions from new development to maintenance.

Monday, May 18, 2009

Yes and...

I had the opportunity to listen to Chic Thompson this past Saturday. That was a great experience. He is a facilitator and what he does is distinctive. I am fascinated by people who have the presence to look at a problem up-side down. We often say that we want creative solutions but we often don't mean it.

Typically we have a problem and we approach it in a top-down manner, looking for a solution. We employ logic and use the analytical part of our minds. We neglect the artistic part of our minds and lose some of those skills over time. What Chic does is force us to look at problems with that part of our minds and identify different classes of solutions. Look at this post, so far it is 100% analytical.

He forces people outside of that comfort zone and reframes the question. Instead of trying to think about a new marketing strategy he asks, "What are 5 things you would NEVER want to do with this product?" Bam bam bam bam and bam. Now how can we turn those 5 things into opportunities?

He also took us through the process of spiralling a product to look at the composition and how changing that composition can create unique new products and opportunities. I really enjoyed this event and I look forward to more people who change the dynamic like him.

Friday, May 15, 2009

Surprise!!!

I love surprises. Christmas morning I come downstairs and I get surprises from my fam. My birthday I get a surprise. Father's Day is usually good for a surprise. Generally I love surprises, but there is one time in which I don't like to be surprised.

I do not like to be suprised by new applications at work. This was recently the case. I attended a meeting in which the business told me that they had developed a new application to collect and process some specific information. I work with these people everyday. I consider myself to be more a part of their team than IT. But there we were, 5 of us sitting around a table on Friday afternoon talking about the new application that needed to go live on Monday morning.

These things are just the way things are. No matter how much you pound the pavement, no matter how much you are a part of the team, there are always going to be instances in which the left hand is doing its own thing. I was not happy on Friday, and I waited until Tuesday to say my piece. I didn't want my anger to get the better of me. Waiting until I was cooler and able to look at the issue more objectively was a good thing. I made strong arguments about the approach and the products that were selected. We all sat down again on Tuesday afternoon, in response to my email, and developed alternate strategies that are more likely to be successful.

But if you are in the business, don't surprise IT with a new, fully developed application. Make IT a partner during the development process. We have done this type of thing before and those lessons that we have learned are painful. Let us help you to avoid learning them yourself, the hard way.

Monday, May 11, 2009

Going Green in IT

There is a lot that we in IT can do to help the environment. One thing that we are doing right now is phasing out traditional desktop computers. We are moving to be a laptop-only workplace for several reasons. It makes sense for contingency operations, but they use less power and have a somewhat smaller footprint. If we could just convince the manufactures to put them in smaller boxes we would be even better. The really big deal, in my opinion is that we recycle all of our old equipment. Most of it goes to schools (after a careful sanitization). What doesn't go to schools gets recycled.

We have a lot of support for Alternate Work Schedules (AWS) and I can see the difference on the roads. Mondays and Fridays especially seem to have a lot less cars. This is due in large part to people working 4-10 hour days or people working 9-9 hour days (and having a day off every other week). I used to work the 4-10 schedule and it was great. I had every Wednesday off and spent it with my kids. It was a lot of fun. But it doesn't work for all roles in the organization and I found myself working on Wednesdays. Thus I came back to the more traditional schedule. But a lot of roles in IT are a great fit for AWS.

A little further on this point, I am a lover of Live Meeting. I have accomplished the same thing that formerly cost a lot of money and had people flying all over the place and staying in hotel rooms because Live Meeting is so good. As a service it is virtually 100% reliable, there has only been one instance in probably 50 meetings in which it didn't work perfectly. I can sync up people from across the country and and walk and talk them through the work, and it is very effective. Bear in mind, it can't replace all of the in-person meetings, there is still a lot to be had from shaking someone's hand, but Live Meeting can be extremely effective for getting the work done and in a way that is kind to the planet.

As with most things, there is a lot of opportunity to perform efficiently when you scale the operation. How many servers are supporting Outlook in the government? I'll bet a lot. How many servers would we be able to retire if we switched to something like Gmail? I understand that there is a risk, but that risk is no greater than the risk that existed when we first powered up Outlook or CC Mail years ago. That risk can be mitigated by bright, creative people who find solutions. The Google server farms operate at a significantly higher level of efficiency than what most government server rooms can. We should be looking at the services that can scale and focus on aggregating them in Centers of Excellence and turn off servers.

The newest thing I'm interested in is the footprint from my PDA. I am now convinced that I would be much less effective without it and could never go back. But I plug it in at night and it pulls power even when it doesn't need it. I wish there was a way for these devices to pull power and then just go to sleep when they are full.