The template is formatted nicely for you in the link at the end of this post. I also want to state, nice and early, that this template is adopted from a MSF document. It has proven itself a nice risk management template for me in a variety of software situations and does not tend to overwhelm anyone. Even clients who lack technical knowledge tend to get it and appreciate it.

These are the column names and description of what information goes in the columns. The .xls contains all this information and looks nicer. I cannot present a table well within WordPress. Sorry about that. Go ahead and use it. Say nice things about me if you like it.

Risk Management Fields:

• Risk ID: This is a simple numeric identifier for the risk. We have to keep track of each risk, independently.

• Description: Summarize the risk. What is the issue at hand, who and what are the players involved, what is the concern? Be as high-level as you can be. No need to get bogged down in details here. Document what is immediately relevant and make sure that the Risk Owner has full understanding. This document should provide an overview for stakeholders but not overwhelm them with detail or technical information.

• Impact: If this risk becomes a reality, how big of a deal will it be? Obviously, this is subject to a degree of context. Some teams may feel that not building RSS feeds into their System is a horrible misfortune, because their SEM campaign depends upon it. Other organizations will not be overly concerned with RSS feeds, since all their content is reserved for members. Use 1-3 for “not a huge problem”, 4-7 for “considerable problem”, 8-10 for “major problem”, and 100 for “showstopper”

• Probability: How likely is it that this risk will manifest as reality? This may be tough to determine, but look at Historical Information, talk to your experts, and nail down your best estimate. This will be a percentage: 1% to 100%. If it is 100%, immediately consider the risk triggered and look to the contingency plan.

• Exposure: Impact times Probability = Exposure. You need to do a little math here, sorry. This will represent how “exposed” your project is to the risk. Do you have a gaping hole in your armor, or are you pretty well insulated against tragedy? At minimum, this lets you see what the biggest risks are. Leveraged a bit more, it can show you what risks are truly worth immediate consideration and action.

• Contingency Plan: What are you going to do when this risk becomes a reality? This is your backup plan, and it doesn’t hurt to have more than one. It does, however, make sense to have a primary contingency plan because you are going to have to take definitive action when the time comes, and you don’t want to have a bunch of meetings to determine the next steps. Congingency plans should be as unrisky as possible. It makes no sense to lay out a contingency plan like “Fly to Mars and find the secret element that will save us.” Write up a primary backup plan, and note others if you have identified them. Do not, however, spend too much time coming up with alternates. You want one safe Contingency Plan.

• Trigger: What will tell you when this is no longer a risk and is now a reality? Usually, the trigger will be an event or a set of conditions. When the trigger event occurs or the trigger conditions manifest, you immediately move to your primary Contingency Plan. There should be no wishy-washy triggers. A trigger is a trigger, and when it is triggered, you take action. Just like a gun. When you pull the trigger, you can’t debate the bullet. I mention this because when it comes to HR or other sensitive issues, people may waver.

• Risk Owner: Who is responsible for keeping tabs on this risk? Usually I recommend that the PM is the Risk Owner, but it may make sense for someone on the development team (like the Dev Lead) to be the Risk Owner. They may have intimate knowledge of the System that the PM does not have . I have seen the Risk Owner be the PMO, in which case they better not be too busy.

• Mitigation: What are you going to do to make sure that the risk does not get triggered? Essentially: how are you going to control the risk? This will come from conversation with your stakeholders. I recommend having a Risk Assessment meeting and bringing key stakeholders together. Add the mitigation field as you go, but call it what you want.”Mitigation” is a very formal term.

• Adjusted Impact: With your Mitigation and Contigency plan, what is the projected impact of this risk?

• Adjusted Probablility: With your Mitigation and Contingency plan, what are the chances that this will still happen? Again, this is meant to measure the value of your Contingency and Trigger.

• Adjusted Exposure: With your Mitigation and Contingency plan, what would the Exposure be? This is meant to make sure that your Contingency Plan is an effective one.

Update 12.10.2009: Somehow, an older version of WordPress included a “feature” wherein someone was granted the ability to augment the Excel document. I do not know why, but all attempts to update it have failed. Good news: all that is missing is a Risk ID column (identity field) and a Description column (where you describe the risk in barely good enough detail).

Download: MIT Technical’s Risk Management Template

I hope this is useful for someone. It has been adopted from Microsoft’s Solutions Framework, streamlined and changed a bit. I find this more universally applicable.

Josh Milane

I like building Test Cases from Use Cases. I do it for fun, sometimes.

Last week however, we were presented with a sudden deadline. We had no forewarning. We were not prepared. The project was dormant for a long time, and out of the blue it was revived as an emergency go-live. I had not seen that happen before. We were in a position where there was no formal testing plan, no test cases, and certainly no Use Cases. All we had was our basic knowledge of the context of the software and the functionality that had been added (this was a version release).

Our development team had not worked on this project. Those developers had long gone, off to greener pastures. They left behind spaghetti code held together with chewing gum and toothpicks that nobody understood or particularly wanted to understand. It was a classic ASP site, and we had moved to .NET some time ago.
No need to lament upon what you do not have, right? What we had was a list of features – contained in sales literature that had been distributed to customers some time ago. A list of features is a list of functionality. One might say that a feature is a Functional Requirement. If you know what the software is supposed to do, you have something to test.

You cannot test without a testing plan, period. Even “Let’s just click stuff and see what breaks” is a crude plan.

If you don’t know how the software is supposed to work, it cannot be tested. You can see what it appears to do, and you can test what it appears to do, but that is almost a self-fulfilling prophecy.

So, in our case, we had a list of features and could extrapolate a list of possible Use Cases. Sadly, there was no time for Use Cases. We had to go live in a few days.

We wrote User Stories. I hate to admit it, but we did. This was a case where the argument for User Stories was clear. They would provide a narrative we could test against. It would not be very finely detailed, and it would not be as thourough as I would have liked, but it would be something to test against.

We started with the basic (high level) functionality. If there were problems at that level, we needed to know ASAP. I think it is important to identify the show stoppers as soon as possible. In a scenario where you are not familiar with the spaghetti code that supports your implementation, you really need to make sure that new features have not completely blown you out of the water. I have seen something as small as lengthening a textbox totally destroy a UI, and I have seen something as simple as the user entering a comma instead of a decimal point make mincemeat out of data.

The high level functionality was easily written into “Sunny Day” User Story scenarios. “Blue Sky, Smiling Sunshine” scenarios are where the user does what they want to do and encounters no surprises, the software behaves perfectly, and the user has a flawless experience. These were simple to articulate.

After writing these up in straightfoward narrative, we went through and tested these User Stories by following along with the Sunny Day Scenario. A few bugs showed up. Thankfully, through disciplined Bugzilla tracking and a talented development team, we squished these with impunity.

(Bugzilla = Open Source and Open Source makes me happy.)

After tackling the obvious, we tested the same functionality in different browsers. It is surprising how many things break in IE7 or FireFox. Part of me can’t understand how this is possible if we have standards and develop in adherence with them. The other part of me knows better.

From there, we pretended to take off our development hats and forget everything we knew about the software. You can pretend to be uninformed or completely incompetent. You can go through and click the wrong links, leave mandatory fields empty, do any number of things that should be handled by validation routines or error handling. You can pretend.

Bring people in who have nothing to do with your project and have them attempt to act out the key User Stories. See what happens. Make note of what they do and especially what they do that you didn’t expect them to do. Document everything as you go along – not just after you feel you have completed a test case. Document what you do as you are doing it. Otherwise, it may be very difficult to reproduce something. Remember, you do not have a Test Case. You are flying solo, in unchartered… er… skies?

Be sure to click every link and press every button, even when they are not relevant to the task at hand. They make software that does this kind of mundane task, but I did not have access to it at the time and you may not. You can choose to outsource this gruntwork to QA houses. They will be happy to charge you $120 an hour. It is your choice if you want to engage them. I don’t tend to like that approach. Throwing money at QA is fine, but not when it is hurried and ambiguous QA. Without a formal testing plan to map to, there is almost no accountability for the QA consultant. Consultants need to be able to be held accountable if they are to be a wise investment.

I recommend making a a simple .xls that you work off of as you go along, filling in a “test case” number, a descriptive title, a field for the initials of the brave tester, a field that describes expected System behavior, a pass/fail field, and a space for notes. This may wind up being valuable. It may obviate that there is a general issue with a specific type of validation, or that a URL keeps mapping back to a hardcoded URL that points to your staging server, or otherwise clarify issues that would otherwise exist only as anecdotes.

Finally, bang away, trying to break it. Put erroneous values in deliberately. Hit “back” when you are not supposed to. Be crazy. Wear a funny hat. Try to make the software choke, cough, or worse.

There is no such thing as testing without a testing plan, but for us, this approach has worked pretty well – and yielded some rudimentary documentation we were able to point to afterwards. Start with the happy scenarios, move to the exceptions, then shimmy to the downright silly, ugly, and hacky.

It isn’t the ideal way to do things, but it is a heck of a lot better than just assuming it works.

I certainly don’t recommend this approach, and would probably deny that I wrote it, but sometimes you have to work with what you have and do the best you can despite the circumstances.

Josh Milane

I have worked on several “portal” projects in my career. Here is a list of the ones that I can think of right now, at the end of a very busy week:

1. A portal to allow Union members to check on their benefits, file grievances, and essentially do whatever we could allow them to do via the web in reference to their Union membership

2. A portal to allow an organization to manage all of its content, publish it to different websites, spawn new websites based on predefined templates, and create reusable tools for the “children of the portal” sites.

3. A portal to allow salespeople and store owners to keep inventory, sales, and company-related documentation and metrics up to date in order to streamline, simplify, and centralize business processes

4. A portal that functioned as a dashboard for a collection of Real Estate agents who were managing the same properties and responding to the same sales inquiries

These sites are all very different. The most complex was the second one because it was built after a lot had been invested in the conceptualization of the “child” sites and the organization sponsoring the project was committed, totally and utterly, to seeing that vision through via the portal. The portal was seen as a natural way to organize something that would otherwise require some repetitive effort. A good CMS could have done this as well, but they had other goals that it is not important to get into here.

But then, what is the same between those four projects that allows them to all be called “portals”? They all have a particular context. The term “portal” is often ambigious, chiefly because it is a term that has been adapted from common language and made specific to an aspect of technology. It is the latest meaning that has been added in the Dictionary definition of the word. A portal is an entrance. None of the aforementioned projects stand out as an entrance. They stand out as a collection of contextual functionality.

Now, I hate when people do this, but let’s look at what the Dictionary says a portal is:

por·tal1 [pawr-tl, pohr-] –noun

There it is, at number 4. Our portal definition.
Most clients talk to me about a “portal” and have heard the term used in the context of I.T., but have not actually seen this definition. They see it as some sort of web-based home page for everything that they want to do as a person, an employee, a luge enthusiast, and any number of things.

In many ways, it is a personalized home page. However, that is far from all that it is. The meaning has been extended to mean a place where functionality with common or complimentary context is presented. iGoogle is a portal of sorts. MyYahoo is a portal of sorts, and the Union’s website is a portal of sorts. A portal’s definition is given by the scope of it’s context.

So in the second portal I mention having worked on, it just so happens that the portal contains functionality to create websites from rough templates. This is a valid portal, as is the portal that allows Real Estate agents to communicate with clients.

The interesting part of portals, besides the fact that they create very niche-oriented homes for sets of Business and Functional Requirements, is in the process of defining the System and Functional Requirements.

It becomes partly a matter of Information Architecture when you are developing a portal that must have children. If I have Functional and Business Requirements for the children sites, do I take those and use them as my founding Portal Requirements, or do I attempt to build a Parent Portal first, then accomodate the children?

It is not a trivial question. If we start with the children sites, it may be that time constraints mandate that non-essential functionality is cut from the project scope. It may be that functionality not common to all children is cut from the first portal iteration. More than likely, if projects with momentum are spawning the idea of a portal, time will be an issue because the project started long before it was actualized in the form of a portal.

Ideally, we would start with the Requirements for all features of our portal. If this includes the ability to generate websites with unique content and functionality, than we would have to build that ability into the portal scope.

When we are developing a portal that will include the ability to spawn distinct sites, functionality that does not require customization (maybe a login procedure) helps minimize development time, scope, and cost. We only have to develop it once and can reuse it across sites.

However, if one of my sites needs to have drag-and-drop page elements and no other do, we are doing a lot of work to accomodate that one site. Ideally we would do it at the Portal level so if a site comes along in a few months that requires the same drag-and-drop functionality, it is there ready to be reused.

In this scenario, the places where the “child” sites do not resemble each other are the places where the most significant work (and the most debate) will occur. Not only do we need to do a different kind of scoping, we need to build the functionality to be forward-minded and extensible. Or at least, good OO theory would have us do that. And of course, before we do all of that, we have to show a solid Business Need to justify the custom development.

A portal is not just a home on the internet. It can be a toolbox of sorts or a number of other things.

I have found that when you are developing a portal, it is best to establish a good set of Functional Requirements, working from the ground up instead of working from the top down. This is hard, because most people will try to envision the portal as a whole.

Walk your users through what they want to do. Interview them and see how they envision using it. Make “Barely Good Enough” Use Cases or Use Case Diagrams if you can get away with it, and see where the overlap is. Chances are, a bit of natural negotiation will occur and while site A might want to do something *this* way and site B might want to do something *that* way, it becomes apparent that *another* way is easier to develop, easier to use, and actually – closer to what the users really want.

The functionality that is not shared across sites falls into a different model. We have to look at it as we looked at the portal. What is it that the functionality is accomplishing? What are other ways that we can imagine accomplishing this functionality? What does it resemble? Can we build it so that it can be customized, or is it truly a “one-off”? If you are using something like Ektron, Joomla, or SharePoint, do they offer any OOTB functionality that can be leveraged? This is where a lot of money gets spent in development and risk is assumed. It is no uncommon for scope to change, and if you put 300 hours into developing something custom only to have that custom functionality removed from your scope, you just lost a bit of money and time.

If possible, you can also phase releases of this kind of portal. Start with what is common. There will be Discovery during development just like there was Discovery during Discovery. Software projects rarely exist in a vacuum. By phasing the portal, you can allow time for ideas to mature and change. Once users see V.1, they may see a natural extension of what you have built that will satisfy their requirements for something custom.

Use Cases should be generic and built as though the platform has not been determined yet. Do not box your developers in, and do not commit to any technology in your Use Cases. In a project involving a portal, this is especially important, because Social Networking and Collaberative Software is an amazingly dynamic world to be in right now. What you spec today might be light years behind tomorrow. This is always the case, but a portal requires users to partcipate for it to have value. Again, extensibility is vital. The ability to have to portal function cross-platform is becoming increasingly important, with portable device use and portable device users becoming more demanding.

When you are developing the functional parts of your portal (portlets), you should keep it in mind that these mini-applications often function best under the “less is more” model. If your portlets are providing functionality that is not UI-centric or graphics-centric, dont forget about your Web Services and dont forget to have an overall data model that accomodates them. It is easier for a lot of portable devices to swallow portlets than to swallow entire portals, and Web Services communicating with Web Services communicating with Web Services becomes more simple if your apps are developed simply, sleekly, and with open architecture – a simple WSDL.

There is an emerging standard for applications that aggregate functionality such as portlets. I always think it is a good idea to develop according to standard, even if your specific implementation is entirely unique.

Another kind of interesting thing that happens during portal brainstorming sessions and the weeks that follow is that folks hear about a “portal” being developed and they want to see if you can give them access to their gmail through it, the weather forecast, do videoconferencing through it, and any number of things. Some people will be offended if the “Corporate Portal” does not take their unique request to heart. A good technique is to have a formal meeting in which you establish the business need for each scope item, and simultaneously creating a list of items that will be held off on until V.2 of the portal comes around. People are much less offended if you do it this way, and will often want to stay in touch with the effort so that they are there when V.2 scoping begins.

In conclusion, regardless of what your portal will be used for, it is only sensible to start from the ground up and capture user requirements, mandate elucidation of the business need, and keep the larger picture in mind. Do not let emotional investment in any particular feature outweigh the business need of the project as a whole.

- Josh Milane

MIT Technical, Boston

I have been struggling lately. It is a private battle, and I don’t think that it shows.

I am consulting part time with a team of Project Managers that is used to writing Use Cases that read like miniature novels, complete with detail including prose such as, “the User will click the red button in the lower left corner of the page that says ‘Click Me‘ and then they will be able to share content.”

I have no delusions of grandeur. Well, maybe I have a few small ones (I think I can cook fish pretty darn well). Still, I know that as far as this particular organization goes, I bring a new perspective upon Use Cases. The PMs that I am working with are not technical Project Managers (but they are very talented) and although they have had formal Use Case training, the lessons did not stick. The PMO did not enforce what they learned and did not work to doccument and uphold Use Case standards. The reason for this is too complicated and potentially boring to get into. I’d rather keep rocking your world with this spine-tingling account of my Adventures in Documentation.

People will tend to gravitate towards what is comfortable, and since the development team was used to receiving Use Cases with sketches inside of them, when I proposed the “Barely Good Enough” approach that they were taught, I was largely ignored. My proposal did not accommodate their expectations and so a small degree of panic and a larger degree of resistance set in. This is to be expected, and there are ways to deal with it.

One way to deal with it is to stick to your guns and start small, see the larger picture, stay the course and offer your opinion without presenting it as gospel. I can certainly think of more noble causes than Use Case Evangelism. However, for whatever reason, I truly believe that documentation is an astonishingly powerful tool and am proud that I am fairly skilled with it. I don’t know if this explains it, but the idea that you can – through effective documentation – take a maldefined, nebulous, ambigious idea and turn it into a reality that people can use and benefit from is really cool to me. The entire process of project Inception, through Scoping, Requirements Gathering, Execution, Design and Development, Testing, and then Implementation is held together by this thread of traceability.

I think it is a fantastic when you can apply discipline and keep this traceability clear, clean, and lucid. It can ensure that you arrive at your lofty goal. It can to connect you to your vision much like a fishing like connects you to dinner. This traceability is invisible unless you know what you are looking for, and it’s one of those things I just happen to get a kick out of. It requires a lot of fine detail and an expansive perspective upon the bigger picture.

So today, as we were had a conference all regarding Requirements Definition and were looking at the more detailed technical end of things, it became apparent that this SharePoint 2007 implementation will require the development team to retool many of the existing classic .asp files. Some data-driven Flash needs to be migrated and coded to operate within the new environment. In the case of these Flash files, this means that interfaces will have to change.

When this became obviated, the room of Project Managers was stunned into silence. I heard it. They were going to have to redo their Use Cases. There were at least a hundred Use Cases affected.

This simply should not have happened.

Use Cases are supposed to describe the functions that the System will accommodate and the actions that an Actor can take upon the System.

In Use Cases, an Actor “indicates via the UI” and does not “click the red button that says “Click Me” in the lower left corner.” At least, they are supposed to.

So I have been the renegade consultant, quite leery of explaining *again* the veracity of proper Use Cases for fear of lynching. (Not really. We all get along very well.) I tried. I really did. I stated the case gently, firmly, and in every non-offensive way that I could. That is what I was hired to do.

People listened, too. They even understood. However, when they went back to their desks and started documenting, old habits took over. Even when there are not time constraints as significant and scary as we are dealing with, people tend to do what they can do quickly, with the least amount of pain.

I am the first to admit that Use Cases can be especially tedious. I think part of the reason that they are tedious is because you are forced to document things that seem really obvious. (Or very complicated, of course.)

I also think that the assumptions that are made when things are deemed obvious are what leads to a lot of problems in software development. Assumptions make an ass of u and mption. Or something.

I was quite pleased that I did not have to redo any Use Cases and that a small victory for “Barely Good Enough” was won. I do find it odd in some ways that the argument for less “technical” detail would have to be argued when technical detail is what causes pain to folks who are not familiar with it. You would think people would welcome the chance to write less, but better, docs.

No, I do not think that naming page elements is especially “technical”. A lot of other folks do, however, and at first glance I understand.

But again, a lot of resistance comes from the corporate culture and like all things dynamic, corporate culture will change. I expect resistance will start to wane. I hope that I don’t come across as preachy or too self-assured, but it felt pretty good to have even that small moment of vindication.

As a consultant, you often find yourself working with people who are unfamiliar with your toolsets and methodologies. Sometimes you are all alone with your specialized, otherwise useless tools. It was great to have some of my speeches elucidated via real life.

Some of the documentation PMs and BAs produce look scary to those who are not familiar with them. This is part of what is happening right now as well. I asked a woman to look at some UML that I drew up today and said that she could not understand it.

I asked her to try. I asked her to just read it.

She could. She just didn’t know it until she tried. It was, in fact, pretty easy.

It was a decent day in some ways, and I like seeing people smile because of UML. I also like seeing people inspired to learn about Use Cases.

I am, in fact, odd.

- Josh Milane

MIT Technical, Boston