GMail vs. Exchange

I read a very good and very fair Computerworld article today about organizations considering a move from Exchange to GMail. In my agency, in which we can't drop any more servers into the facility because we don't have any additional power, this makes perfect sense. Organizations should commoditize email, calendar and contacts if the cost-benefit analysis works in your favor. In my situation, we could re-purpose a lot of hardware by shifting those capabilities out of the four walls of the Agency. That could free up resources to do new and interesting things.

I was surprised that the article didn't just jump on the Google bandwagon. If you just read the first page, you will get that impression. But reading all the way to page 6 leaves you with the notion that if Google could catch-up the features in its calendar product then the analysis would definitely trend in their favor. I must confess that a lot of the references were directed towards analysis performed last summer. That is about 11 months ago and as I read it, I am assuming that some of that gap has already been closed. In fact as I'm writing this I just reviewed the capabilities in the Android calendar and I think it is close, but not quite what I get in my outlook calendar. I consider myself to be a power user when it comes to calendar functions because of the number and complexity of the meetings I schedule.

The knock on the GMail solution has always been security; that we can more finely control the security provisioning of the Microsoft products. I am getting the sense that with the Google Apps, that is not the case. A couple months ago Google reported that its single sign on security provisioning system was hacked by someone. In reading the detailed stories in the NY Times, it was clear that other companies email systems were also hacked, but that those companies chose to not publicly disclose the incidents. Were they referring to Microsoft? It's hard to say. But I trust a company more if it can accept that bad things happen and tell people that it has taken steps to correct the issue. I think Google has done the responsible thing. I have seen too many zero day patches from Microsoft to think that they have always acted as responsibly.

Anyway, I have been a vocal proponent of considering GMail as an alternative to Exchange/Outlook. This article proves that there is merit in at least doing the diligence in considering it. I'm not saying the the GMail solution is the answer, only that it is ripe for consideration.

How an Internship should be Structured

I was tasked with reviewing 160 applications last week for an internship with the Department. These opportunities are targeted towards rising sophomores with an expected graduation of May, 2012. within the panel we had some disagreement about how the internship should be structured.

A colleague of mine was of the opinion that the student should have a deep dive into one or two specific fields like Enterprise Architecture or IT Security. I was on the opposite side, arguing that the internship should provide each student with some visibility into as many of the IT disciplines that we can.

Neither position is right or wrong. Both are valuable to the student. But strategically the executive sponsors of this internship should have identified more of the vision for the program. They should have identified either a broad and shallow or narrow and deep exploration of government IT work. From a panel perspective, it could have made a difference for a couple of applicants if we were looking for a generalist versus focused knowledge of a specific area.

PMP Credential Verification

I must confess that I knew that there was some way for people to verify that I have received my PMP, and that I'm in "good standing", but I had never actually taken the time to test that process. Well, I've done it, and I'll share how.

First, the PMI, for as good as they are, could really benefit from having an Information Architect on staff. I have no idea how to navigate to this page from their splash page, but eventually you need to get here: https://www.pmi.org/CertApp/Registry.aspx. An IA could really help them to structure their content so that navigation would allow someone to logically drill down to find this content instead of searching Google. But that discussion is for another day...

Once there, simply fill in the lname, fname, country and credential type and it will search the database of credentials to let you know if the person is in there. I think it is very unlikely that someone would lie about having his or her PMP credential, but you never know.

Integration Services

Integration services is probably the most squishy of squishy work. I think that everyone in IT would agree that it is an important component of any systems or applications development/maintenance program, but how can we know that the integrators are doing a good job? I have put some thought into it and I think that I have come up with at least a few tangible and objective (measurable) deliverables that will help to lend some visibility into this process.

When we need integration services we have at least two components. It could be more than that, but let's stay with two for the discussion. We must treat the integration work as a separate mini-project. We should still march through the design, testing and security review processes that we would on any other project. Thus I think a System/ Sub-system Specification should indicate the design. An Integration Test Plan should identify how we should test. A Test Results and Evaluation Report should identify the results of the execution of the test plan. And Finally we should receive an Interconnection Security Agreement that identifies what and how data is being shared. Hopefully with these concrete and measurable deliverables we can begin to make this squishy work more objective.

Emphasize Process over Product

I have built many work statements. One of the things I like to consider during the closing phase is writing down the lessons learned. I always look at the variance between the initial work statement and what actually transpired. The goal is that there should be no deviation; that the work that was written down matches what was delivered.

I have found that variance to personally decrease over time. Certainly some of that can be attributed to the fact that as a Project Manager I have greater experience and more intimate knowledge of what needs to be done. While it would give me great pleasure to claim that, it would not be very accurate. Instead, I made a very fundamental change in the work statements that I develop, and what I do seems to be somewhat unique. At least when I talk about it with my peers, it seems to open them up to considering new possibilities.

Years ago when I developed a Statement of Work I would go to great lengths to objectively identify the system or application to be built. I would identify the requirements, the "ilities" (reliability, scalability, maintainability etc.). Then during lessons learned, I found that I was way off. I found that at a generic level my requirements were OK, but when I made them measurable and specific, that locked us (the government) into a course of action and was a constraint that hindered the project.

I tried something new at HUD. Instead of identifying the product, and incurring all of that risk, instead, identify the process to be followed. It makes perfect sense when you think about it. Requirements are an artifact of the process, but in SOWs, too frequently people try to include them. Rather than describing the final system or application I described the process to be followed that will eventually deliver that final system. I identify how many Requirements meetings we will have and what a Requirements meeting looks like. I identify how many Design and QA sessions and what they look like. I identify how many development iterations we have and how we know when they are successful.

I don't waste effort in trying to describe the product any more. I think you need a crystal ball or an oracle or a time machine to try to describe the box that the solution should fit in so early in the process. Instead I only describe the process that will be followed, and, if you have the right development team, they will get you to the right solution.

A Matter of Choice

I find it interesting that GSA is asserting that it is the only agency allowed to award Government-Wide Acquisition Contracts (GWACs). In a recent article over at FCW, GSA is battling the National Institute of Health over its GWAC and NASA is worried that they are next in the frying pan.

In this area I must confess that I am sort of a free market kind of guy. I think that others should be allowed to negotiate their contracts. If they negotiate a lower price for some things then the federal government should be able to buy at that lower price. I also think that GSA should not have a monopoly on the negotiations. If GSA is the only game in town, and they have no competition in the GWAC business arena, then I think that it is likely that certain aspects of that service will deteriorate, e.g. quality, timeliness, price. It is price that I am most worried about. As I've mentioned many times before, it is through effective competition that we (the government) achieve competitive pricing. If GSA has no competition, then I worry about competitive pricing on GWAC purchases. If GSA is truly negotiating the best prices then they have nothing to worry about anyway, right?

In the interest of full disclosure, I have been part of a team that has purchased through GSA and their GWACs in the past. I found the service to be better than my expectations. While I received very good service, I still think that there should be competition in this sector. That should continue to foster innovation and GSA, NASA, NIH and others should always be looking for a competitive advantage over the others. That is in the government's best interest, and really the peoples' best interest.