Why didn't we need a prototype for some of the projects?

Question

This is not about why do we need a prototype. Or the opposite of Why don't we need a prototype. It's about why some of the projects that we did without a prototype/not even thinking about one...

Most of our projects (small scale IT/software development), did not require a prototype. Some were RAD, some were developed using typical waterfall methodology or agile. For major projects prototypes were required. During a recent project meeting, I was challenged to explain why prototypes were required on some projects and not on others. ". . .[h]ow do you determine that you don't need a prototype?"

For each of those projects, what made us to not to create a prototype..? I am cracking my head... I could only think of following reasons (and I am not fully convinced):

• Client has no time for prototyping and needs accelerated development
• Requirements and process to be improved are Crystal clear
• Smalle scale projects that can be written within a day to 7 days or with max 2 weeks
• Some enhancements or modifications to an existing system

All of the above has to follow the basic project life cycle. Also for e.g. does a migration project (say from Java to C#) better off with a prototype of without (I am not asking specifically for migrations, but it could be one of the situations in real life)?

Answer 1

In my experience prototypes and wireframes really come into their own when you are dealing with unknowns or with lengthy/involved stakeholder sign-off.

In the former case a prototype can help to clarify functionality, architecture etc ahead of development, hopefully avoiding re-work and ensuring everyone has the same understanding of what is being built and how it will work.

In the latter case the prototype helps to clarify requirements (and can be used to change these), manage expectations and test assumptions.

If your project methodology is very user-oriented then I think prototypes (or at least wireframes) are probably essential but only if they are actually used to guide development. I've seen situations in which a client/stakeholder was delighted with a prototype only to be disappointed by the changes that were made between its release and the final product. Communication is the key as always!

I'm not sure if there's a hard a fast answer to your question - it's one of those 'it depends' ones unfortunately - but these are two scenarios in which I think you need prototypes.

Answer 2

The purpose of a prototype is to learn something you didn't already know, something that is vital (or perceived to be vital) to the success of the real project. All projects have some unknowns, and prototypes often can help address those unknowns.

Some projects don't have enough unknowns to warrant a prototype. If you're building something very similar to what you've done before, for example, you probably aren't going to need a prototype. If the scope is small you aren't going to need a prototype.

If, on the other hand, you are building something completely new, a prototype can help. If you're using new tools or new libraries, a prototype can help you learn how much overhead those new tools or libraries are going to add to the project. If you have a customer that is struggling with visualizing a completed project or feature, a prototype can help bridge that gap. And so on.

The original question was "Why didn't we need a prototype for some of the projects?". I think the answer to that is simply that you already had all of the information you needed to be able to plan and implement the project, and had no need to improve the communication with the project stakeholders.

Answer 3

The Role of Prototyping

Prototyping and its close cousin wire-framing are not really project management controls. Rather, they are engineering practices designed to:

1. Create a skeletal mock-up for rapid feedback.
2. Test the soundness of an engineering idea through an approximation or scaled model.

A project plan might include a milestone for delivering a prototype for review or evaluation, thus providing a feedback mechanism for the project. However, whether or not to include such a milestone is fundamentally an engineering or business decision, and not a de rigueur process-control technique.

Just as story spikes help reduce the cone of uncertainty for a project, a prototype or wire-frame will often clarify aspects of the project that might not have been self-evident at the outset. However, whether or not the project needs these spikes or interim deliverables is a going to vary from project to project.

In other words, your mileage will vary.

Answer 4

The prototype can be looked at from the perspective of the engineer, solution architect, or project manager and I believe each role has it's valid reasons to impose a prototype.

Here we are only concerned with the Project Management context and the answer to your question is completely about risk management. Does the PM care if engineering or UX design feel they need prototypes? Only if the PM perceives sufficient risk when they don't.

Prototypes have the potential to mitigate at least three types of risk:

1. technical feasibility
2. usability
3. miscommunications (or claims thereof)

The project manager should be empowered to insist on a prototype on the basis of risk if necessary. The reverse is not true: the PM should not be able to use schedule or resources to veto the need for a prototype if engineering or other stakeholders want one.

Looking at your four examples, projects 2-4 provide a rationale to support minimal risk (crystal clear, short, minor). Without some other indication that there was risk I think it would be wasteful to include a prototype. On the other hand, project 1 doesn't provide a rationale to support minimal risk. You don't mention the nature of the project, but unless it fell into the 2-4 categories the elimination of the prototype actually increases the risk.

I think you just need a written policy (or verbal if your company is writing-averse) that clarifies the relationship between the perception of certain types of risk in a project and the need for a prototype. That should answer their question and also provide a potential process improvement for the future.