Wednesday, December 22, 2010

Trust

It's easy to trust someone or something when the stakes are low. For example, that the coupon that Borders sent to your email is going to work at the store. If it doesn't work then I miss the opportunity for 10% off. A nuisance, but really low stakes. It usually works, and Borders builds up a stock of credibility with me as a consumer.

This is the background for the story of what happened to me yesterday. I left work a little late (15 minutes), and needed to pick up my kids all the way across town. I usually take Route 7 the whole way and get there in about 1.5 hours (I know don't get me started on that one). But I left late, it is the last week before Christmas and my route takes me past the biggest mall in the area. In short, it was a perfect storm for me picking my kiddos up late. So I've really been using the Google navigation service, Latitude, a lot lately. It is nice to just see how long it is likely to take me to get home. But on Monday when Latitude told me to take a little deviation from my regular route I trusted it which resulted in shaving 10 minutes off of my travel time. Not too bad. Cha-ching in the Google trust account.

Yesterday, I turned on Latitude as I was leaving work. It started me on my regular course, West on Route 7. But then a minute later it was telling me to make a U-turn and head West on Rt. 7. I was stopped at a red light so I looked ahead to see where it was taking me. I assumed it would drop me onto 395 West. The proposed route was to 395, but not West. It wanted me to go East, towards DC.

So here is the big moment. How much credibility has Google built up in my consumer account? Apparently enough for me to trust them and drive in the opposite direction that I thought was right. This is kind of funny, but the car ahead of me, and the car behind me did exactly the same thing I did at that moment. I could see the woman ahead of me had Latitude running on her phone on her dashboard. I assume that the car behind me was too because all three of us did the exact same thing at precisely the same time.

Instead of taking 395 West, I hopped on 395 East. Latitude wanted me to get exit at Glebe road. Google was right, Glebe road had no traffic on it, because the exit ramp was closed for some reason. There was a squad car at the top and bottom of the ramp and I couldn't take it. Thus when I went past it, I thought, "Uh oh, I'm probably in trouble now."

Latitude rerouted me immediately. My new route was only 3 minutes longer and directed me to the GW Parkway, to the outer loop, the toll road and eventually home, at which I arrived at the regular time I typically arrive.

I think it is easy to trust something when the stakes are low, but when they are high, picking your kids up on-time, that is when it is hard to trust something. I trusted Google this time and they didn't let me down. They built up even more credibility in my consumer account and I would be inclined to take other leaps of trust with them in the future.

This is why they give away things like Google Maps, Latitude, Blogger, GMail and many other things. So that you will trust them more. Sure it helps to drive traffic to their revenue generating services like search, YouTube, Android and Picasa. But more importantly, when they make a play for something like GoogleTV, people who trust the Goog will go for it. I don't know that I'm there yet, but they just got a big deposit in their trust account with me yesterday.

Monday, December 20, 2010

Performance Plans

First as a Division, the decision was made to standardize the Performance Plans. This is a good idea because, my feeling is that most people were working of of their old performance plans that have just gone unchanged over time. So each time a new person was hired some effort was poured in to create a performance plan that was reasonable for the position to be filled. The problem is that they weren't adjusted every year and that people in the same branch with identical positions likely have very different performance plans, especially if they were hired more than 2 years apart.

Thus the decision was made to standardize the performance plans within the division. This was such a good idea that the decision was made to actually standardize them for the entire office. This is reasonable because everyone who works in OIT will generally have the same basic elements, but they can be tailored to the actual position and grade.

Thus everyone has a Civil Rights element. Everyone also has a Leadership, Mission Support, Communications, Customer Service, and COR/COTR. My part was to help shape the COR/COTR element. For the standard I really spent some time focusing on the parts that everyone must do regardless of the situation. So, everyone must keep his or her certification current. Everyone must complete the financial disclosure, so that we can avoid organizational conflicts of interest. Everyone must keep a copy of his or her designation letter. Background Investigations are initiated for new contract personnel. Review invoices etc.

I also worked to make the standards objective. ACMIS is the system that we use to track required training and certifications. Most of the rest is paper or records that should be easily produced. The next part for me was to assemble the pieces for what "Exceeds" that standard. I wrote in aspects of the work like chairing technical evaluation panels, developing work statements, mentoring more junior acquisition personnel and debriefing unsuccessful bidders.

Anyway, I found this to be a very satisfying experience because for everyone in my office, here is one part of your performance in which it is completely objective, or at least as objective as anything can be.

Monday, December 13, 2010

Performance Evaluations Don't Need to be Stressful

I had a real slow-down on posting new and interesting messages up here because I was on a detail for 8 weeks. This was a great experience for me. My detail began the last week of fiscal year 10 and ran through the first seven weeks of FY 2011. I specifically asked for this time frame because I wanted to have a very specific experience. I wanted to lead the performance evaluations for the new branch we had started.

I know what you are thinking, "Who would ask for that type of assignment?" Me, that's who. The reason is quite simple, I manage people all the time. As a Program and Project Manager I I lead people to accomplish difficult objectives. However I don't have the actual authority to evaluate the performance of the people who support my programs and projects. I provide feedback to their manager and that feedback is mixed with other stuff to eventually generate the annual performance evaluation. I had often been a contributor to that evaluation but never the author of the evaluation for federal employees. Now, I can say I have.

There were 6 employees in the branch and I sought feedback from the people who were responsible for monitoring their performance over the course of the past year. I then synthesized that feedback and generated an evaluation rating. I then justified the rating for each person to the Division Director. Next, I scheduled the performance evaluation meeting with each person and shared the feedback and offered some ideas for ways to improve.

These are supposed to be difficult and stressful situations. I worked hard to take the stress out of it by making sure that everyone understood the process before we began. I think that is the key. People aren't stressed out by the performance review, people are stressed over not understanding the process. We in the federal sector don't make it easy. The process can be confusing. The different between Outstanding, Superior and Fully Successful can be confusing.

For me, I think the labels are confusing. Outstanding is higher than Superior. But look at the definition of Superior - something which is higher in a hierarchical structure of any kind. Maybe it is just me, but the method of the ratings is not intuitive and that can cause confusion which leads to stressful situations.

Anyway, I worked hard to make sure everyone knew and understood the process of the evaluation. Next time, I'll write about what I did to establish the performance plan for FY 11.

Thursday, December 9, 2010

TechStat Update

Back in March I wrote about a new initiative from the CIO Council called TechStat. It was an interesting scenario because the project was clearly in trouble. It was behind schedule, over budget and still held a significant amount of risk. Flash forward 7 months and, I wouldn't say it is in the clear, but I think it is safe to say that the mood has changed.

I read this article from FCW this morning which touched on the Web-Based Supply Chain project under USDA. What they wrote is accurate. The initial plan for the project was to have a 1-time cut-over switching from the old mainframe system to the new web-based one. In order to make that happen though the data conversion aspects needed to go smoothly. They didn't, which put the project into a tough position. The business process automated by this system is a lengthy one, more than 2 years. What they chose to do was to let users close out last years and current orders with the old system but require the new orders to go into the new one. This allows the team to avoid the pain of the data conversion while realizing the value of the current investment.

I don't think WBSCM is going to be the darling of the administration, but I am pleasantly surprised by the turn of events. What is also surprising is that the project was able to make some recovery. My opinion is that when a project is under that much pressure and scrutiny it can't recover because nobody is able to make a decision; everyone is so worried about making sure that they aren't to blame that decisions that would actually help the project recover never get made. It is refreshing to see that someone is making the tough decisions that are likely to get the project to the finish line.

Wednesday, December 8, 2010

Let's Go to the Food Show

Yeah, it was one of those days, hard to beat. I had the opportunity to participate with the State of Maryland yesterday as they held a food show. "What is a food show?" you ask. A food show is where the Food Service Directors for school systems get together to consider new and different food items that are available to be served in the school systems.

When I say consider, I mean eat. So yes, I had some cafeteria food yesterday but it was nothing like what I ate when I was in school. I had food that was spicy, ethnic, and had tons of flavor. What I didn't have was a bunch of fat, added sugar and sodium. I did however have a lot of vitamins and fiber. So the food on the menu at the school is very different from the food of 20+ years ago.

I found it interesting to witness the process of getting some of these foods onto the lunch table. Convincing the Food Service Directors is only the first step. These food processors must also demonstrate that their foods are marketable and will be eaten by kids. Then, the Food Service Directors must consider price and figure out which food items in different classes offer the best value to the school system. It isn't a confusing process but it is a deliberate one, which is good.

Anyway, this was a great experience that provided me some visibility into the Food Distribution business in my Agency.

Tuesday, December 7, 2010

Hi, It's been a while

Sorry to have been quiet for so long. I participated in a detail opportunity and didn't offload any of my regular work. I was already quite busy managing 9 projects under the Special Nutrition Programs, and then add to that the acting chief of a new branch here, the Operations and Maintenance Branch. Trust me, I had a full plate. The interesting thing about this assignment was the fact that I was the acting chief during an interesting time.

I started the week before the end of the fiscal year (last week in September) and finished the week before Thanksgiving. So I was the chief for about 8 weeks. The part that made this interesting for me was that I had the opportunity to manage people during the most difficult time, annual performance reviews. I know, everyone always says how much they hate that process, and anyone who has been a manager probably complains about going through it. For me though, that was the exact experience that I asked for.

You have heard me harp on IDP's over and over again. I often say that IDP's are more than just training, they are a map to get you from where you are today to where you want to be tomorrow. For me, I have the leading people, I have the communications, I need the management experience. I need to be able to answer the interview question, Have you performed annual performance reviews for government employees? Now I can answer "Yes" to that question and that helps me to stay on track, and will eventually get me onto the next stepping stone.

So I'll write more about the great experiences I had later, I just wanted to take a moment to say I'm back.

Wednesday, October 13, 2010

My New Gig

I don't know if you noticed, but I haven't written much lately. I was already fairly busy, but I'm now also the Acting Chief of a Branch here. This is a really tough task because I didn't offload any of my current work and now I have additional duties that I'm performing. So I'm managing 9 different projects that are in various stage of development and operations and managing a team of 6 people.

The good part of this detail is the timing. I asked for a very specific set of experience. I asked to manage the end of year performance reviews. Gasp all you want, but I asked for that specific set of work.

Performance evaluation is uncomfortable for many people because of what you don't know. Its like being afraid of the dark. People who claim they are afraid of the dark aren't typically afraid of darkness, but rather the monsters that can't be seen because it is dark. You turn the light on and people can see that there are no monsters and thus, no fears.

Well, performance evaluation is similar. People are anxious about what they can't see. This is heightened for for the 6 people I'm managing through this process. I'm new to them (at least in this role). They don't know me and haven't had an opportunity to build rapport with me. So the opportunity for fear is much greater than it would have been otherwise.

My approach has been very deliberate. I can't turn the lights on, but I can help them to understand the process and what they should expect. On the 30th I sent the team an email outlining the performance evaluation process. I sent each person a copy of his or her mid-year performance so that he or she could see the performance elements and any feedback from that event. I then asked each person to consider identifying the activities and accomplishments that I should review while preparing the Performance Evaluation Report. I have received that feedback and am currently writing those evaluations.

I also asked each person to consider writing an IDP. I wrote about those last week. But I want each person to really think about development in ways that are more than just training.

Finally, because of the realignment, (which created the new branch and the reason for me to be the Acting Chief), peoples' performance elements are not necessarily aligned to what they are actually doing. This caused some consternation with them when they were identifying their accomplishments. Thus I have the additional task of baselining the performance elements for everyone in the new branch.

All of this is to tell you that I'm quite busy. Sorry, I can't write more.

Tuesday, October 5, 2010

IDPs

People don't understand why I'm such a big proponent of Individual Development Plans. The reason isn't because it is some magic bullet that makes people more effective or efficient. No, the reason I have been such a strong supporter of IDPs is because it forces two people to have a conversation.

I don't know why this is a problem but Supervisors and Employees do not generally have good conversations. Here is the typical scenario:
Employee - I would like to take training class abc.
Supervisor - Sure, submit form 123 to me and I'll sign it.
Employee - Thanks.

In this scenario the employee got exactly what he was looking for and the Supervisor was helpful in making it happen. The problem is what didn't happen. The Supervisor didn't ask how the training experience would fit into the Employee's short and long-term goals. Further, the Supervisor didn't ask how the training experience would benefit the organization and whether it is even consistent with the needs of the office.

That is why IDPs are so important. An IDP forces the Employee and the Supervisor to have the conversation about the trajectory of the Employee's career. Where does he want to be in 2 years, and 5 years? What are the types of experiences that will help him to get there? This may include training classes, but take the blinders off and look at more than just traditional classes. What the Employee needs is specialized experience. That is what the Supervisor should be looking to create an opportunity for. When it is a knowledge gap, sure, program training. But if the employee wants to go somewhere, professionally, and it aligns with the needs of the organization, it is the Supervisor's job to help him achieve it.

So, an IDP is important because it forces a conversation that doesn't happen nearly enough.

Tuesday, September 28, 2010

The Best Places to Work

Every year the Best Places to Work rankings are released and every year the Nuclear Regulatory Commission is at the top of that list. Every year I work for an organization that isn't in the top third. But I think the rankings aren't a good indicator. There are things in my agency that are really good and I'm sure that there are some things at Nuclear Regulatory that are not-so-good.

The interesting thing from the survey is that this year you are able to compare organizations. It wouldn't be interesting to compare my agency against the NRC. But maybe it would be interesting to compare my agency against the Department average. When I did this I was surprised to find that the agency beat the departmental average in most categories except Training and Employee Development.

Strategically as an agency that should be an area of emphasis. I encourage others to perform som analysis on the best places to work survey. You may discover interesting nuggets like this.

Monday, September 20, 2010

Problem Solving

Seriously, as soon as I had written my last post (Missing Requirements) I received an invitation from the CIO in a different Agency inviting me to view a demo of a product called PCAT (Public Comment Analysis Toolkit). This is a product created by Stuart Schulman Ph.D.

That name was very familiar to me. A couple years ago when I was working with CNPP on the 2010 Dietary Guidelines, that was one of the products we had considered in the cobbled-together solution that EPA was advocating. That product would assist with the analysis portion of the process.

What PCAT does is grab the data from FDMS and then crawl it. It will create a Wordle type of output but more importantly it will help by creating a list of categories. Even better though, you can specify your own list of categories and then quickly tag comments to relate them to one or more categories. Finally, it is entirely cloud-based. It is essentially Software as a Service, so there is no hardware or applications to install or maintain.

The product certainly has matured in the last 2 years. Mr. Schulman explained how the application was created. It was really funded through some research grants from the National Science Foundation. It was conceived as an approach to dealing with unstructured data. Is it perfect? No. But I have to admit, it seems like it has really been a 1-man show so far. It would be interesting to see what could be accomplished with a small development team and about 4 months. I suspect that it could have a much more focused benefit.

Anyway, that was pretty good new to help address the analysis portion of the work. We have an enterprise license that will carry us through March, and that will likely be what we need to address the immediate concern. Long-term, I still think that EPA through their Regulations.gov/FDMS have a responsibility to nullify the need for applications like PCAT by making their solutions better, but until that day comes...

The other issue, the data load issue, getting the content from the box that the mail room provides into FDMS had some movement as well. We could pay another Agency in the Department somewhere in the neighborhood of 30 cents per page and they will load the content for us.

Thursday, September 16, 2010

Missing the requirements

People who know me, know that I'll tell you the truth. When a system or an application misses the target, someone needs to step up and address the deficiency.

More than 2 years ago I worked with the Center for Nutrition Policy and Promotion (CNPP) to help manage the 2010 Dietary Guidelines. This is actually a very prestigious project. Every 5 years USDA and HHS get together to consider and revise the guidance we issue to all Americans concerning things like how much fat is appropriate, how many green vegetables should be eaten and meat and the components to a healthy diet. This information flows into almost everything else we do, like the Food Pyramid, the School Lunch programs and even the WIC program.

Anyway, to initiate the process for considering adjustments to the Dietary Guidelines a series of public comment events is convened to engage academics, nutritionists, advocates the industry and everyday people in the process. Two years ago, we wanted to use Regulations.gov and its back-office counterpart, the Federal Docket Management System to host this process.

As you can see we eventually decided to not use those services for this work because they didn't meet our requirements. Specifically we need the ability to categorize each comment that we receive. If the Environmental Protection Agency, the organization that operates these two applications that support the business process, would have implemented one very easy change then we would have used it. We would not have spent money to go a different direction and acquire services from a company that specializes in this area.

The change is simple. Allow the Agency to identify a finite list of categories that will be tied to the comment. If someone comments through the Regulations.gov interface then he or she is able to chose one or more of those categories. If the comment is received by the Agency (hard-copy or FAX), then when we upload the comment through FDMS we would assign the category on behalf of the commentor. This is a simple change, a drop down list. It would be comprised of one column in the code table and one column in the comment table.

At the time, two years ago, the executives from EPA pushed very hard for us to include the Dietary Guidelines in their services. We cited over and over again that this requirement had to be met. Both sides were equally dug in. I found the technicality that broke the stalemate. Regulations.gov is required for all regulations and policy memorandum. Since we were talking about the Dietary Guidelines ADVISORY Committee, it does not fall into either of those buckets and we were free to choose whatever service we want. Essentially what we will be putting out is advise, and is not binding one any person or program.

Flash forward two years. This past summer I worked with the WIC program on the public comment for a proposed Rule (essentially a change in their regulations). This had to be published on the Regulations.gov/FDMS service. They received around 8,000 comments and we struggled mightily. There are two distinct business processes that must occur. The first I'll call the "Load Process". This is when the Agency receives boxes of paper comments that are mailed to us concerning the proposed regulation change. We have to expend effort to scan, OCR, load the comment into FDMS and then key in the meta data concerning the comment like who it is from and the address. This must all happen so that the person who make the comment is able to go on Regulations.gov and find the comment that he or she sent in.

The second process I'll term the "Analysis Process". Of all the comments that we received, the Agency is responsible for expending effort to analyze the comments to understand how many we received concerning each of the primary categories of comments, that we have addressed all of those comments, and that they were considered and impacted the development of the final rule.

In the Agency we recognize that we can't make the first problem go away. For as long as we receive paper comments we will have to bear the effort of digitizing them and loading them into FDMS. But on the Analysis process, shouldn't we be able to use FDMS, the system that has each and every comment to perform the Analysis? If EPA implemented the ability to assign one or more categories to each comment that would likely address the need. But since they haven't, we are forced to acquire a system or services that will help us to do that separately.

So I brought this to their attention 2 years ago. FDMS just had a major upgrade. I assumed that this no-brainer feature would be in there. Nope. Not even on their radar.

But more importantly, this isn't a need just with my Agency. Every organization that wants to change a regulation has to go through this exact same rule-making process. How is it that a thousand people aren't screaming at the top of their lungs that this simple change, which would save tens of thousands of work hours, and probably millions of dollars hasn't been implemented.

Now I'm helping on a project that expects to receive 50,000 comments. I called my colleague over at EPA and asked her what's up? I know it isn't her per se, but as an organization you need to understand the overall business process. Maybe you don't meet all of the requirements with the initial release, but I would definitely assume that 2 years later, you would look to leverage greater value for the user community.

Monday, September 13, 2010

Phishing

A dozen or more times per year I get a cold call from a software vendor, recruiter or news organization to provide information. The vendors typically want to know what types of products I'm planning on buying in the next 12 months. The recruiters want a Project Manager or developer for some client. The newspapers want me to sign up for their magazine or stuff so that they can claim a certain level of circulation.

In all of these situations the person cold calling me is looking for new information. They would call them leads. Please know that I have nothing against any of these people, in fact, we (the government) need them just as much as they need us. It is a symbiotic relationship.

But, we all now must complete the annual cyber security training. Part of that training involves the idea of phishing. While I believe that each of these people has completely benign intent, we (government employees), really shouldn't be giving out any information.

Thus, when ESRI or Oracle calls to inquire about how much we use their products and what we'll be spending next year, no. In terms of technology, if an unscrupulous person knew the technology stack we were using, that person could be more efficient in penetrating our defenses.

The recruiter who wants the name of a good PM in the Agency, no. If I gave you the names of the PMs or developers I work with, you could use that information for a social engineering attack.

Or when FCW comes calling for the subscription, but I need to identify how many people I work with and the scope of those projects, no. Anyone who needs me to supply information in order to feed the relationship is necessarily cut off. This could be both of the situations above, the technology stack and a social engineering attack.

Am I not being pragmatic or realistic? Maybe. But you know what, when these people call me, I don't know them at all. I can't vouch for them. Who is to say they really work for the organization they claim. So, sorry guys and gals. It isn't personal, I'm not permitted to supply the information. I would if the rules allowed me to, but until the rules change, don't bother.

Tuesday, August 31, 2010

HTML 5

I know that I've had a fairly prolific month, and after yesterday's tome, I definitely wasn't thinking about writing anything today... until I read this article about the Geekiest Music Video Ever. So you go there and type in the address where you grew up and let the video play. It's not like anything I've seen before, at least on the Internet.

The best way to describe it is American Graffiti, but real time. Check it out, the Wilderness Downtown.

Monday, August 30, 2010

Federal CIO Listening Sessions

You might remember a few months ago I wrote about Tech Stat, the series of Program Management Review meetings on several projects, one of which I am tangentially involved with. Well, 26 Projects have been officially put under the microscope. The project I consult on is on the list.

In addition to this though, Mr. Kundra, the OMB CIO, came to the Department for a Listening Session. It was clear that he had already been to several agencies already, including Commerce and the Department of Justice. I must admit that I was surprised by the informal nature of the session. First, instead of using the standard government 'panel discussion' format he had us re-arrange our chairs into 2 concentric circles so that everyone could see and share. Then there were some brief remarks by the Department's CIO followed by some remarks by Mr. Kundra, and then it was kind of a free-for-all.

There was a person taking notes on the themes that were discussed. There was one funny moment. Someone asked who would really tell OMB the truth about a project that was failing, I instinctively raised my hand and then realized too late that I would be the only person in the room. Since I was on the side, I didn't think anyone would notice. Wups, the note-taker totally caught me and pointed out later that I was the only person in the room who did that.

I took a couple notes about some items that are worth discussion. First, Mr. Kundra quoted that the rate of IT project failure from the 80's through the 2000's has increased. I think I would like to challenge this idea a little bit. I don't think the rate of failure has actually increased. I think the reporting of failures has increased. I think that before Clinger-Cohen the opportunity to obscure IT project failures was significantly better than it is today. As such, we have significantly better visibility into failures than we did before. I will grant you that we are working on several orders of magnitude more IT projects than we were 20 years ago, and the actual numbers of failed projects is bound to be larger, but I submit that it is likely that the percentage of failures is very likely to be less than the 80's and before. For sure that failure rate was better in 2009 than in the mid 90's, the first year of the Chaos Report (from the Standish Group). Regardless, my point here, is one of reporting, that we think there is more failures because we are more effectively reporting the failures.

Next, he used a great metaphor, he said that the purpose of Tech Stat is to "shine the light" on troubled projects. That is a really good metaphor. First, when you shine the light, you let the project know that external entities are watching, like a spotlight in an interrogation. But second, when I think of this, I think also think of a lighthouse that let's sailors know where the rocks are on a rough sea.

Finally, anyone who knows me knows that I can't keep my mouth shut. The idea that I floated, and I think it had some traction with the group was in designing the solution too early in the process. I thought about this over the weekend, and I think that I have a metaphor of my own for illustrating the issue:

We need an IT solution, let's just call it "The Box". The Box promises to do great things for us, so there is a lot of momentum to go it. But The Box is an expensive proposition, and even though we expect it to transform the business, we have to line up all the ducks to embark on the project. Thus we develop our OMB 300. Here is the first problem. The OMB 300 needs to be developed (they say 2, but it is actually) 3 years before we can begin the project so that it can be included in the funding cycle. Not only that, but we have to really design the box to create the OMB 300.

That's the problem. My project to create The Box, includes both requirements and design work. But 3 years before I start I am forced to design the solution? How can that make sense?

There are tons of people who evangelize Agile development. I've even written about it a couple times (one | two). But the problem is that the government hasn't learned how to balance the government's need to know what we're buying from both a capital planning and acquisition perspective with being Agile to meet business needs. So I go ahead and I develop the OMB 300 Business Case for The Box. I get approval and then I go ahead and develop my Acquisition Plan, work statement etc. for buy a system that looks like The Box.

Three years after the business community was so wound up to transform the business with The Box, we actually get started. The fallacy is that the requirements and design processes are complete. They can't be because we are limited in the scope of our solutions to what was written in the OMB 300 and what was written in the work statement. So rather than survey the entire field of opportunities to meet the need posed by The Box, we are limited to what we identified before any in-depth analysis was performed.

So now, The Box, the project that was intended to be this transformative project for the business, is now a box that confines our thinking and limits the range of solutions that we can consider. Please leave out-of-the box thinking at home, because we are building The Box, like it or not.

But it is really hard to get all these ducks in a row, and it seemed like a really good idea 3 years ago, so we should probably go for it. Never mind the fact that the leadership has changed and that the priorities for the business have changed. Build The Box.

So we embark on the project, and it is a big project. Let's say that it takes 3 years to build and deploy The Box. We get all the way to User Acceptance Testing and the business reviews The Box and they say, "This doesn't meet our needs." And I say, "How can that be? I built exactly what you told me. Here it is." I pull out the OMB 300 business case to show the business leader.

The problem is that in the most likely scenario, 6 years have passed from when the business had all that momentum to do something, and the point at which The Box was delivered.

Why can't we buy more things in bulk? Wouldn't it be cheaper if, when my wife and I have a child, we could go out to the store and buy all the milk to satisfy that child until he was 10? Or cereal? It seems like I buy a gallon or two of milk and a box of cereal every week. Each of these incremental purchases would be far less costly if I could really buy in bulk. The reason we don't make those ginormous purchases is because those staples, milk and cereal have an expiration date. They are no longer good after a specific period of time.

But we think that requirements act differently. We think that once we identify the requirement, in this case, to build The Box, that we can go about our business, build the box and deliver it and it will be considered just as valuable on the 2,190th day (six years) as it would have been on the 365th day.

Any Project Manager's ability, heck any person's ability to see beyond the horizon of 1 year is not very good. Because of this, we can make strategic plans that cover swaths of time, but we don't make tactical plans with that kind of time horizon. We make tactical decisions in one-year increments. Part of the reason for this is because requirements have a Freshness Factor.

A requirement is a requirement under very specific conditions. For example, the widget goes from A to B to C when we talk about designing The Box. But in the intervening 6 years, we have realigned the organization (probably twice), and B doesn't exist any more. So if you deliver The Box with the A -> B -> C routine, that won't work anymore and I'll need you to fix it.

This will cause a deviation in the cost and schedule of the project, and will, by the Standish Groups definition be labeled as a "Troubled Project" since it has variances in scope, time AND cost.


What's the solution to this dilemma? My solution is to not describe The Box at all. Think about it, the work that we will be paying for, the reason for the OMB 300 Business Case is to acquire services that will help us to build The Box, as in the solution. In the OMB 300 or Exhibit 53, and on the work statements we need to not describe the final solution. Any language that decribes The Box will necessarily limit the thinking when it comes to requirements and design to meet the business need. Instead of describing the product, describe the process. I've written about this before.

Next, know that the requirement for the business need has a freshness factor. If you can deliver it timely then you will satisfy the business completely. If you deliver it later than timely then the level of satisfaction will be less than complete. The hard work is to identify the specific metric for Timely. Remember, I am not kidding about the ability to see beyond a 1-year horizon. My recommendation is that you deliver functionality into the production environment in 1 year increments. You can still do big things. In the example above, The Box took 3 years to develop. OK, break The Box into parts or modules and deliver them over that timeframe. That is what a PM should be good at, chunking the project.

Consider the OMB 300 to be the strategic plan, but then consider that each year will have a tactical plan, or an action plan. You can't begin writing the follow-up action plan until you are 50-75% done with the current one. This will help to alleviate McConnell's Cone of Uncertainty, which, for Mr. Kundra, was one of the things he said he would take away from the discussion.

Tuesday, August 24, 2010

WBT Dev Part 12 - Finishing Touches

Nothing ends at 11. It's a really odd number. So this is my last post in this series, an even dozen. You can check out the initial post for links to the 11 others as well.

After you render you will see a group of files like this:
Notice, this is a 16 minute video and only 7 and a half megabytes, that is outstanding. Camtasia can't make it pretty for you. You'll notice that in my Module 1 I have a banner and navigation that will bounce you from one module to the next. Camtasia can't build that for you. You have to custom code that.

It isn't difficult, in fact, I just used Notepad to code this one. I copied some framework code and then customized it in Notepad. This was a little tedious because I had to code, then save then browse to get the colors just right, whereas if I was using an HTML editor I would have had a color picker in the WYSIWYG editor, but getting the editor installed for this limited use project would have proven to be more trouble than it is worth.

Anyway, once you put in the HTML wrapper you send it up to the website and let it go. It couldn't be easier.

This was a fun project to work on. It took more effort than I planned, but I think the finished product is of very high quality. I did this project, not because I long to be a developer again, but rather because I needed to prove to my agency that we can develop high quality Web-Based Training (WBT) using the stuff at a regular workstation. The Camtasia software isn't part of the standard image. It is about $180. The microphone and headset are fairly common, but cost no more than $60. So for an initial investment of no more than $240 anyone can create WBT like this. The hardest part is knowing what to do, and hopefully this series has taken away some of the fog around that. Good Luck.

Thursday, August 19, 2010

Actually Making it Work

I had a meeting yesterday in which the contractor mentioned that the System Requirements Specification (SRS) would be delivered next week. We took a few minutes to go over schedules to ensure that we will have people to review the document.

But then I noticed something. The work that we were talking about was simply a document review. For the stakeholders on the project, they didn't understand that this is a big deal. Let me take a moment to explain.

The PMBOK does an awesome job about telling you how the processes should work. It does an awful job of grounding those processes in reality. When you read the PMBOK, you will understand that you have to manage the scope of the project, and that there needs to be a Change Control Register. But what the PMBOK fails to identify the point from which you manage CHANGE. In a practical sense, the first second you sit down in a project is a change right? Everyone has their different assumptions and ideas, and for most people, those ideas evolve into consensus. Wouldn't that be change?

No. We begin to measure change from what we call the requirements baseline. The artifacts that comprise the requirements baseline are going to be different based on the organization's preferred templates and the software development lifecycle that is selected. But in many instances the requirements baseline is comprised of any of the following:
  • System Requirements Specification (SRS)
  • Functional Requirements Document (FRD)
  • Data Requirements Document (DRD)
  • Requirements Traceability Matrix (RTM)
Once these documents are "Accepted" we (the stakeholders, the development team, sponsors, PM, all project participants) have agreed to the Requirements Baseline. This is important because this baseline is the point from which we manage CHANGE. Before we get to a point at which we have accepted these documents we don't really have a baseline and as such nothing from which we can objectively say, "That is a change." After these artifacts are approved we then have an objective point from which we can measure change.

When you have this conversation with the stakeholders you must help them to understand that when they review the SRS, they are agreeing to the requirements baseline.

Be careful though because the second you have this conversation the inverse reaction can also happen. Someone could say, "Well, I don't think I can approve the SRS because it might have something that we'll want to change later." If you are prepared as a PM, you'll address this issue as well.

I then went on to tell the stakeholders that "perfection" is not the goal of the SRS. I only do Agile (spiral) development for just this reason. In the SRS, our goal is to have a document in which the average person would agree that yes, it is generally correct. The reason for this fuzziness is because we are going to have design and QA sessions, we are going to review functionality a couple of times and we are going to have User Acceptance Testing. Thus, the things that are not perfect in the SRS, and the things that are not fleshed out in great detail will be reviewed as we progressively elaborate the requirements into design and design into features.

Also, you must tell your stakeholders that some amount of change is acceptable. Just because we have agreed to the Requirements Baseline doesn't mean we can't or won't accommodate changes to it. But rather, I will force the stakeholders to be more deliberate about the change. If we want to change the name of a field, and the developer uses resources to implement that change, we don't want to change it this week only to change it to something else next week, and, God forbid, change it back to what it was originally a couple weeks later. I have been on projects that have done that and I learned a lot from those situations. No, if we're going to implement a change, our goal is to only change it once, and when we make that change it will be perfect.

Finally, we may get to a point in which we have a mountain of changes, more changes than what can be accommodated within the scope of the project. Here is what my commitment has been to the stakeholders: We will address your NEEDS, and if we have the resources to handle it, we will address the WANTS. This is important. If you have a mountain of changes, you have to be able to identify the things that are necessary (NEEDS) to get past acceptance testing versus WANTS. This is why we prioritize the change control register. Needs will bubble to the top and wants will not.

Monday, August 16, 2010

WBT Dev Part 11 - Rendering the Project

Check out the first post in this series for an overview of the project.

We are very close to the end of the project. Here is where it all comes together. But to do it well, you must be deliberate in how you go about it. We have the video, the audio, the captions, the markers, the quiz, now, all we have left is to put it all together and watch a movie. Click the "Produce Video As.." link to open that menu.

We already know that we are going to use the "Custom Settings", and that we are targeting a Flash output, so select MP4/SWF. On the "Flash Templates" screen I'll choose "One video with TOC" but then I'll jump into the "Flash Options" too. I recommend at least looking at the Flash Options to consider the range of choices.

The first sub-menu in the Flash Options is key for me. It's going to default to MP4, and I really want to get the better compression by targeting Shockwave.
Next, in the audio sub-menu, remember how much trouble we went through to generate a higher quality audio track? Don't mess it up now by selecting "mono". I recommend a "stereo" setting that provides the compression you want.
Next, we spent some time up-front to put our Markers in order. And when we ran through that I mentioned that you would have another opportunity to improve them. Now is the time. Check out the image below. You can make some markers subordinate to others. You can de-select some markers so that they won't be displayed. I typically don't repeat the markers for "Continuation" slides. Finally, and this really annoys me, Camtasia will create a marker called "Answers Summary". It will always display that unless you de-select it. Keep that in mind every time you render. You won't believe how many times I've rendered a presentation and checked it out only to find this dumb Answers Summary in my TOC.
Finally on this sub-menu, under "Controls" you want to create a "Loading Image" and specify it there. If you don't specify your own image you will get a Camtasia loading image, which looks very cheesy. Below is the image I created. When someone clicks the link to open the video, this is the first thing he or she will see while the browser pulls the content. It will likely be visible for about 3-6 seconds depending on the pipe and the traffic.
As you can see my loading image is generic to the overall WBT series and not tailored to any particular module within the series. I could have created a unique loading image for each module, but I think the generic one addresses the need pretty well.

Going back to the main, "Produce Video As..." menu, you are heading next to the "Video Options". Go into the Video Info section and fill that up, it is self explanatory. More interestingly though, under "Quiz and Reporting", here is where you have the opportunity to identify the email address for the quiz feedback. You can see in this instance, that I had a specific email account created for collecting the quiz output, FDPIR-Training@fns.usda.gov. This will allow someone who completed the quiz to send their answers to us.
On the government side, we can monitor that in-box and, if we want, we could send certificates of completion to the people who achieve the right number of correct answers. We can also record which content was quizzed and when (since we have a date-stamp on the email). This can be used to help map usage over time.

One last look-through on the markers and then choose a name for the production, like "Module 1" and hit finish. This will take some time to render. The longer the video the greater the amount of time necessary to render.

Thursday, August 12, 2010

WBT Dev Part 10 - Quiz Time

And now we get to the heart of it. Sorry that it took me 10 posts to get to this point, but everything builds upon itself. Check out the initial article in this section to review how we got to this point.

You'll remember that one of the initial deliverables was a PowerPoint that included the quiz at the end. We're now ready to automate that quiz feature. Take a look at the end of my Module 1 to see what we're aiming for. I found this to be difficult, not because the process is hard, but rather because TechSmith, the people who create Camtasia, didn't have a lot of documentation or tutorials on how to implement a quiz. So here is my attempt to fill that void.

Set-up your quiz, (see the image below), and then choose multiple choice for the answers.

Then you are going to add in the content of the question and you will identify the potential answers below it. Lastly, don't forget to identify the correct answer by hitting the check-box.

But you'll probably notice that my quiz provides the user with very specific feedback concerning how he or she did on responding to the question. If the user got it right, I confirm that and tell him or her why it was right. More importantly though, if the wrong answer was selected, my quiz identifies why that answer is wrong and the right answer. To do that, select the body of the answer in the above image. Then choose "Edit".

Select the radio button to "Customize this answer". Then, in the details box input the custom feedback you want to display if the user selects that answer. The image below displays the title slide in the back, the quiz question and the "Edit Answer" screen on top. In this instance we are editing the first answer (a) to the question.
You are going to need to repeat this process for every answer. I would recommend that you treat the answer feedback as content, and be sure that whoever is creating the content or the quiz not only provide you the answers to the quiz, but also the specific feedback to each answer.

The last thing I need to point out is the fact that in the layers of our production, we will have a new one just for quizzes. You will see a little diamond icon indicating where your quiz is located in the overall production. You will want to move the quiz to the point at the end, right after the last close caption goes black.

Wednesday, August 11, 2010

Project Planning in the Rear View Mirror

There is a Meatloaf song called Paradise by the Dashboard Light. This has nothing to do with that.

I am amazed that some developers think that they are fooling anyone with this. I am working with a development team and they never send me an estimate of how much effort they are planning until after the fact. The amazing thing about this is that they are nearly 100% accurate with the estimates they eventually send. Their level of effort estimates are correct down to the half hour. (I hope my sarcasm comes through here)

Who are they fooling? I know that they are performing the work and then plugging their actuals into the planned effort. Their reputation is sinking faster than the Titanic. This practice is not rare. I have seen it on two other occasions from different vendors. I call it 'Planning in the Rear View Mirror' because they will tell you what their plan is...

after the work is already done.

That does me no good. The reason I need to see your LOE is so I can ensure that adequate funds are in place to support the work. If you give me no time to ensure that funds are in place to cover the work then you should expect a stop work order to be issued because we don't have the funds necessary to cover the balance. This only leads to more difficult situations both on the government side and on the vendor side.

So my strongest recommendation is that you generate the estimate, send it in. Sometimes it will be off. That is why we have a risk management process, to identify things that will invalidate the estimate and work to avoid them. But it is better to be a little off and use the process than it is to completely stop work on a release.

Friday, August 6, 2010

WBT Dev Part 9 - Markers/ TOC

We are are getting really close to completing the development of the Web-based Training. Check out the initial post in this series for an overview and links to the related parts.

This is where we start to get a little technical. I'll try to keep it light. Think about the final product. In this instance we know that we want to have a quiz at the end. That means that the final product must necessarily be a Flash-based product (eith MP4 or SWF). These are the flash outputs. MP4 is the most common Flash type. SWF, or Shockwave File is like MP4's little brother, not nearly as strong or robust. MP4 is a good bet for live action video and lots of motion content. Shockwave is good for slow motion. Now, think about our content here, we have PowerPoint slides, audio, close captioning etc. What we don't have is a lot of motion. This means that I can cheat and go for a really low number for Frames Per Second (FPS). Most TV is 30 FPS (but really it is like 29.97 FPS).

But in our situation, if we have 7 FPS in terms of video, that would be plenty to deal with our lack of action. That just happens to be the rate that Shockwave likes.

This had to happen like this because we want to have the quiz feature at the end of the production. If we didn't care about that, then we could have considered some other formats like Windows Media and QuickTime (.mov). These are good alternatives to consider when you are making those trade-offs between quality and file size. Windows Media gives you a somewhat lower quality (in terms of resolution) production, but the file size is also really low. QuickTime gives you a much higher quality but the size of the file is also much higher. So consider all of this, and remember, as long as you still have your project, you can try out different presentation media without any additional effort. Want to see what it looks like in QuickTime? Just "Produce" (render) the project in the dot-MOV format. After it is done, go back to the project and try rendering it in WMV or Windows Media. Compare and contrast to tweak the variables to give yourself the presentation you want.

But for our project, we are targeting Shockwave. This creates an additional opportunity for us. The Flash formats allow you to create a Table Of Contents (TOC). This is a really good feature because it allows the user to jump from one section to another. In this instance, since we used the PowerPoint plug-in to record our initial video, Camtasia has actually created "Markers" for us that will eventually become our TOC when we render the project. But those markers are probably going to be generic like this one. In this example, I'm mousing over the green diamond to reveal that the Marker Name is "Slide 2".
Either double-click on the green diamond or rt-click and choose "Set Marker Name". I like to have the marker name match the title of the slide. Be reasonable on this though. If the title of the slide is 114 characters in length, you are going to want to trim that down to some reasonable number. In the final product the markers will turn into the TOC, which you can see in the red border in the image below. We'll have a chance to do a little clean-up work on this right before we render it, so don't spend more than 5 minutes on this now.