Risk Management Profile for Web Software Projects?

Question

Hi,

I'm about to start working on a "Software as a Service" website project. This is the first project of this kind I am going to work on, so while I am trying to anticipate any possible risks, I'm sure there will be many more I will not take into account.

Does anyone know of a suitable risk profile boilerplate for this kind of project?

Thanks,

Adrian

Answer 1

I've just recieved this month's web designer magazine that seems to have something similar to this. Do you mean actually running the service or just generally building a project? I found this interesting:

"Interdirect's nine-step process to avoid web design catastrophe"

1. Follow a predefined project delivery methodology.
2. Start with new client/project questionairre/checklist.
3. Hold a 'discovery meeting' to analyse requirements.
4. Define team member responsibilities.
5. Create a functional specification 'blueprint' document.
6. Get the client to sign it off and agree on the specification.
7. Ensure ongoing regular client communication.
8. Present completed work for client approval as soon as possible.
9. Build client trust from the start and make it a priority.

Answer 2

Without knowing type of service, how 'available' for public consumption it is, etc. - I think you can break it down into the standard groups:

Security

• restricted to registered users
• full audit history
• intrusion detection and reporting
• secure connection

Quality

• performance - return results meet required performance
• return results provided in agreed-to format

Maintenance

• defined upgrade path (communication, backward compatibility, etc.)

The template should contain the risk, entry date, status (open, impacted, closed, addressed), mitigation plan, who its assigned to

Answer 3

"Risks" are all (basically) either bad management or bad design. There's little or no probability theory involved.

First, start with any "risk" profile for any software development project. The standard litany of user buy-in, sponsorship, requirements, testing, commitment, etc., etc. None of that changes.

Web-based SaaS doesn't add any new management or user "risks". Users still lie, managers still have unrealistic schedules, customers demand unrealistic prices.

You have to allow time to learn the technology. This isn't a "risk", it's a cost.

1. Unless you've used the framework before, build something small in the framework which you will throw away. A "self-test" or a "proof-of-concept" or a "demonstration". Something that you will not try to evolve into final production code. This isn't a risk area. If you don't build something small and throw it away, you're going to struggle with the technology and fail to deliver on time and on budget.

2. Unless you've got a rock-solid security model in place, plan to spend a lot of time on security issues. There are many threat scenarios, many technical gaps that become security holes and probably some junk software that doesn't address your use cases.

   Everyone likes to pretend that security is easy. "It's just passwords, right?"

   Give yourself plenty of project time to list the actual threats and work out solutions. Mostly, this is easy -- use SSL and digest authentication and proper coding practices to prevent all of the OWASP vulnerabilities. But your situation may have uniquely weird things.

   If you don't leave time for providing architectural support for security at all layers (database, web server, application, operational procedures, etc.) you will create software with security holes.

3. Unless you've got legally binding performance objectives, allow yourself time to do performance testing, find problems and fix the problems. Performance testing is not a 2-week effort after the software is built and before use acceptance testing. Performance testing is an ongoing struggle with a multitude of configurable items.

   Configuration of all the various components is hard; it takes a long time and requires a good load simulator. If you don't allow yourself time to fiddle around with the configurations of all the items (reverse proxy server, web server, applications, database) you'll wind up delivering software which doesn't scale properly.

4. Also, allow time to design (and redesign) the message schema. If you go with RESTful web services, it will take more than one attempt to define the resources appropriately. If you go with SOAP/XML, you'll have to allow a lot of time to get the messages and the WSDL's right. You'll make regrettable decisions here, so leave yourself time to regret them and fix them by changing the messages.

5. Leave a lot of time for unit testing and creating a usable unit test suite. Web services can be annoying to test because you have proper stand-alone unit tests, plus simple Web Services integration tests that should be part of a single, comprehensive suite.

   You'll want to build a test suite that allows you to seed a database with a known fixture, start your servers, execute some client requests, shut the servers down and dispose of the database. Sounds complex, but you'll really want it about the time you start your first round of serious refactoring.

These aren't "risks". These are hard things that you need to leave time for. Specifically, you need to leave time for rework. On a first-time project, you'll make decisions that aren't optimal. You need time, permission and technical support to unmake them.

Answer 4

Take a look at these six steps to managing project risk which lists some do's and don'ts, different types of risks, and points out that not all risk is bad.