Choosing the Right Vehicle

No, this is not a story about cars or kicking tires. A colleague sent me a link yesterday to a story discussing a policy shift at DISA. When I read through it I realized that they are heading into a difficult situation. They should ask around and listen to the experiences learned from other agencies that have enacted policies similar in nature.

I once worked for an agency that had this type of procurement policy. All contracts were Firm Fixed Price (FFP). There was no other option. This policy was a big contributor to the collosal failure of a $6 Million project. The policy forced us to fix the price for contract activities that are extremely difficult to fix. Think about what is required in order to fix the price. We should have a pretty good idea about how many resources we need and how long it will take to reach the objective with the right level of quality and customer satisfaction.

There is a lot of work that lends itself to this contract type. Installing desktop computers, applying patches to servers, performing a Certification and Accreditation are all examples of work in which the scope is fairly defined, the schedule (duration and level of effort) is defined, and quality and satisfaction are easy to manage. This is the type of commodity work that is well suited for FFP contracts. But now switch gears and consider some of the front-end types of activities like business analysis, requirements elicitation and design. This points back to my Chicken or the Egg post. Without sounding to Laurel and Hardy, how long will it take? I won't know until I start the work. How deep are the requirements? I won't know until I know how long it should take.

When we look at and consider a requirement, any requirement, we should consider the full range of contract options that can meet that requirement and then make a selection based on the tolerances of the owner of that requirement.

Consider this spectrum of contract types created by people at Defense Acquisition University's (DAU) Acquisition Community Connection (ACC). On the left side you have Firm Fixed Price and on the right side you have Cost Plus Fixed Fee. Based on things like how certain we are about the estimate, riskiness of the work, and who should own the risk we will hone in on the contract type that fits our requirement. In many instances FFP is the way to go. But look at this chart. Should we assume that DISA is going to be starting any systems development projects? Because if you are initiating that type of work the chart seems inclined towards the T&M side.

Please know that I am not against fixed price contracting. I am however against any type of rule or policy that takes creativity away from the paradigm. If fact I strongly believe that when you are embarking on a systems development type of project that you should have a hybrid contract approach to the work. I believe that Time and Materials components should be used for the business analysis, requirements and design because they are typically difficult to nail down with the necessary quality and satisfation. But once they are, I believe the development (construction), testing and deployment should be fixed in price.

SharePoint for Project Management

I am happy to announce that I have achieved a high level of performance in managing projects. I had the pleasure of attending a brown bag (in which nobody actually ate lunch) at the PMI Skyline Luncheon series this past Thursday. The presenter was a gentleman named Dux Sy. He is the author of a new O'Reilly book SharePoint for Project Management. His presentation went through several areas in which SharePoint could be used to effectively manage projects.

The reason for my happiness is that in my big project I was already doing each of these. The first area he covered was the overuse of email. We never include attachments on email messages. We load the attachments into SharePoint and send links to the stakeholders. We use the discussions to allow people a time and place to hammer out different views on requirements. We have the development team check products in to the site as the official delivery and stakeholders review and make comments to artifacts on the sharepoint. We use the Announcements web part to alert people to news and events. I use the Links webpart to get people to the regulations and other pieces of program content that may be valuable to our work.

The only thing we aren't currently doing that Dux demonstrated was to creation of a Chron file. This is essentially an email address that is an alias for the SharePoint site. I inquired about that as a feature since last Thursday and I have been told that it may take some work to make it happen, but I will be using that too.

If you have a chance to see Dux I recommend taking the time. He is a good educator in this area.

There is one thing that I found to be kind of funny from Dux's presentation. He talked about the virtues of SharePoint because before it PMs were at the mercy of the IT shop to get a website built for a project. His story made it seem like it was a very onerous task to make that happen. I don't remember it like that. Of course I was a web guy before I was a PM, so maybe I had a leg up on the competition. But I remember making project-specific websites at my previous agency and that was equally effective. There I had discussions (bulletin boards) and I had files that could be downloaded. There was work in maintaining it, but no moreso than what I have to maintain SharePoint. Just an observation, but do you know how Plato said that only philosophers should be kings, well, maybe only Web Developers should be Project Managers.

Risk Management Plan

First of all, people usually begin a project without any plan for how to identify, qualify, mitigate and respond to risk. It is an inescapable fact that when we engage a project we open ourselves up to risk. Too frequently we begin the project with no plan for managing risk, but moreover, I think that even when we do have a plan to manage risk we are only managing risk on one plane. We are not managing risk across the entire investment. I will try to make this distinction clear because it is important.

Most, if not all risk management plans are going to be hatched from knowledge or consideration of the PMBOK risk chapter. That is a good start. The processes identified there are solid and are practical for truly managing risk. The problem is that the problem space from which PMBOK prescribes management is too small. Think about it, PMBOK is very concerned with PROJECTS; temporary endeavors to meet a specific need. In this context you shouldn't realize any of the investment related risks; is it the right platform for the enterprise, technical obsolescence etc. You also shouldn't realize any of the detailed technical risks from actually operating the system or application; are you releasing patches to the OS in a timely manner, who has access to the application server.


Thus the PMBOK-prescribed Risk Management Plan is good for what it is, but it is deficient in managing the full spectrum of risk for most of what we do. Unless you are truly running a Ron Popeil type of project in which you can set it and forget it, you really need to consider both the investment level and detailed technical risks facing your project.

Jeepers Creepers where'd you get those...

Peepers. Well, not exactly. In this case I'm going to talk about PPIRS. That's the Past Performance Information Retrieval System (PPIRS). PPIRS is actually just a meta search engine for several different systems used in the federal space. It is run by the Navy Sea Logistics Center.

But before i get into that, let's take a look at the problem it seeks to address. Here's the scenario, you put out an RFP and companies submit their proposals. You have 5 factors that you base your technical evaluation on. One of those factors is Past Performance. It has a 20% weight factor. Does this sound familiar? You review the proposals and each one submitted 3 references for beautiful projects that went extremely well. You might even call the references to verify. Each person you speak with speaks in very glowing terms about the project.

If it happens like this every time, then why do we even bother to call the references? In all the contract awards I have participated in, I have only seen one instance in which past performance was anything but glowing. So why do we bother?

We do it this way because that is how we were told to do it. Some person with more wisdom than us told us that was how she or he did it and we just sort of go along with what they did. That is great for what it is, but I don't feel like I'm getting additional value out of that process. The people I speak with, while maybe they are objective, could be something other than that. What is a guy to do? I want to take the subjectivity out of rating pastperformance. Enter PPIRS.

PPIRS (http://www.ppirs.gov/) data is based on the actual contract record at the time of closeout. My examination of the data for known entities leads me to believe that the data is generally accurate. As such, I would begin my examination of this factor in PPIRS and then rely on submitted information if the offeror doesn't have very much data in that system. Start early though, it took me some time to get into the system. Their verification process took a while.

By the way, why is this a Navy system? This should be sponsored by GSA or Commerce where there is a closer relation to the mission. The system is difficult to use because the GUI is not intuitive, but once you figure it out you can mine valuable information. So, here's to making the review of past performance a little bit more objective.

The First of 5 W's and 1 H

So most people know and understand the 5W's and 1 H. That is Who, What When, Where, Why and How. All of these are important, but most of these are products of the work. One of these must be accomplished before the work begins. That is the Who aspect.

Many people make their fatal (in project terms) mistake right here in who-ville. They think that the person who hatched the idea or that the person who cares the most about a particular project is the only who that matters. That is really wrong. As it turns out there are probably many people who need varying degrees of information concerning your project at various intervals. The key to the first W is to understand them all and their needs.

To meet this challenge we have a great tool. It is called a Communications Management Plan. You have to be careful to right-size this approach, but all projects above a certain size (cost or duration or both) should probably have a Communications Management Plan. The Communications Management Plan must contain the following:

• It must have an org chart depicting the various business units and how they relate to each other.
• It must describe the process to be used in conducting a stakeholder analysis.
• It must describe all of the roles within the project.
• It must describe the different communications channels and appropriate use for each.
• It must contain the stakeholder identification form
• It must contain the stakeholder analysis.

All of these things are important, but they all build and contribute to the Stakeholder Analysis. The S/H analysis identifies the organizational unit of each stakeholder. It also describes the role(s) of each stakeholder. It identifies how the stakeholder likes to receive communication and the frequency. The really big thing though is the Power/ Impact graph. You need to plot each stakeholder on this table to understand which stakeholders have the ability (power) to either positively or negatively impact your project. Once you do that, these are the people who you will want to keep as happy as possible. The people who either have very little power or very little interest or both are less labor-intensive.

If you don't take the time to do this then it is likely that you will try to please everyone all the time. Tough luck. That cannot be sustained over the long term. You have to know which of your stakeholders are the ones to be happy and spend your influence on them. Don't waste time or effort trying to influence people who are inconsenquential to the project.

Was that an almost short post?

PMBOK V. 4

So the updated PMBOK is supposed to be out and available. I have tried several days now to try to get my electronic copy (since I am a dues paying member of the PMI). But unfortunately the process that allows my authentication on the website does not pass through to the PDF of the book. The prevents me from actually getting the content.

Now, I generally like the PMI, but this is insane right? Here we have an entire organization that is devoted to managing projects successfully. It would seem to me that the project to deploy PMBOK 4 fell down a little bit in the Risk Identification area. Perhaps it could have used a little more Quality Assurance and Quality Control? Even after this risk was realized, it doesn't look like they took the time to develop a Risk Response Plan. Finally, I would have to say that their Communication was the most troubling aspect. I am certain that they understand the scope and magnitude of the problem. But when I sent a message telling them that I had a problem downloading my copy of the book do you know what they wrote back? They told me that I didn't install the Adobe plug-in correctly. The truth is that I have correctly installed the plug-in, and it is messed up on their side. That makes me think that they also have a little bit of an issue with Professional Responsibility; if you own the problem, don't try to pass it off as someone else's problem.

But, like I said, I generally like PMI, and have had a reasonable experience with them. I would be interested to see the Lessons Learned report from this project though. Maybe it will be one of the Historical Documents they consider when beginning PMBOK 5.