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.

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.

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.

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.

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.

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.

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.

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.

Happy Passwords Reinforce Positive Feelings

Short one today. Take a look at this post entitled The Psychology of Happy Passwords. If this theory doesn't merit further research nothing does.

Lessons from Greg House, MD

Most people have probably seen an episode of House on Fox. The show is successful because the title character lets his id run wild. He says things that you would never expect to hear, let alone from a doctor. One of the things he frequently says is that patients can't be trusted because they always lie. As a result he sends his minions to break into their houses and search for the truth.

That's great for TV, but that couldn't happen in the real world. Yeah, that's what I thought too, until it happened to me.

Let me be clear, I'm not a doctor and I don't even play one on TV. Nobody is entering anyone's house to snoop around. And maybe lying is a little bit strong, but let's say that the truth was not as forthcoming.

Background, I have been managing a project, not big in terms of $$ but it is big in terms of impact. The objective of the project is to introduce a new correspondence management system. This is an interesting project because, from a technical perspective it is simple. But from a deployment perspective this is the most difficult project ever. Think about it, I am swimming against the tide, and the wind in my face and a boat trying to pull me the other direction. We have 30+ years in which people have been generating correspondence packages. You have your yellow (canary) copies, your blue copies, your white copies, your letter-head copies, the buck-slip, the blue folder, the red folder, the green folder the clear plastic thing, etc. I swear, an entire industry exists around the act of getting correspondence from one person to the next.

I hate to sound formulaic in my approach to the project, but it has served me well. I identified the stakeholders (s/h). In this case the s/h included a bunch of Administrative Assistants, Branch Chiefs, Division Directors, and the front office. We held a bunch of Requirements Gathering Sessions (RGS). We held a bunch of Design and QA Sessions (QAS). The developer built in iterations (3) and we tested after each build to apply course corrections. We held User Acceptance Testing and gathered feedback to prepare for the release of the product. We released the product and held the first big training session. At the end of the big office-wide training session one of the Administrative Assistants asked if I could host a hands-on session just for them.

I begin their hands-on session a few days later. It was going well but about two-thirds of the way through the business process there was a problem. The business process they described was different than the business process that was described during the RGS and QAS. It wasn't radically different, but clearly a couple of important benchmarks of the business process were not articulated. I can say that they were not articulated because I attended the RGS and QAS and I know that we had achieved consensus with a depiction of the business process and what the secretaries were saying was that their steps in the process were not represented in the final system.

I don't want to make it sound trivial, but once we had the newly enhanced understanding of the business process it is relatively easy to adjust the application to reflect those new benchmarks. But for me, the problem I am struggling with is; how could we have spent all that time on the business process and end up with a flawed understanding?

I think I know why, s/h lie. I'm just kidding. Nobody lied, but I was definitely not sensitive to the organizational dynamics that will still exist among the s/h. In retrospect, I should not have been surprised to learn that when the secretaries are mixed in with the Division Directors and the Branch Chiefs they nodded their heads and agreed to the vision of the process identified by management. It wasn't until there was a meeting that didn't include management that I got a more practical understanding of the business process.

My problem was that I saw all s/h as equal. Rank or grade doesn't matter to me, I just want to have an accurate understanding of the business process. However it did and does matter to them. They didn't chime in to correct their boss' understanding of the process during the RGS and QAS. That would be overstepping their boundaries and it's not their place (their reasoning, not mine).

So, no, all s/h aren't liars, but as a PM, you need to create an environment in which they can tell the truth. They want to tell the truth, but they don't want to look like they are going against their supervisors. I didn't create a safe environment for them this time, and I need to do a little re-work to correct it, but I'm more sensitive to this issue now.