Volume Number: 25
Issue Number: 10
Column Tag: Business

Humane Project Planning

All we know about starting an Apple business, from the idea, to product launch and beyond

by Michael Göbel and Oliver Pospisil, Inspired By Life

Michael: "Oliver, I'm not satisfied with the outline view."

Oliver: "What bothers you about it?"

Michael: "I don't think so many users really need it."

Oliver: "What feature could be more important?"

Michael: "That's exactly the problem. Right now, it's just more of a gut feeling."

Oliver: "Ok. Let's tackle the problem from another side. We need an outline view to enable the user to put the elements into hierarchical order. Which feature would add more value for the user?"

Michael: "Initially, we had planned on offering attachments in version 1.x. So shouldn't we still do it? When I checked our decision log out again, it sure looks like both of us had very strong, positive arguments for the outline view and for the attachments, too."

Oliver: "Yes, we had opted for the outline view for one of our potential customers. Since we've now adjusted our overall strategy, let's think of a way to implement both."

Michael: "Ok, since another developer has teamed up with us, that should be doable. I'll get back to you on this as soon as possible."

We will now be your guide during the following planning session. At the end of this article, you'll know what it takes to come up with a plan that's worth the time invested and that provides the right trigger for non-coding activities like a press release.

"[Planning] is the last refuge of those who cannot dream," Oscar Wilde.

Most people perceive a plan to be something that makes them feel kind of guilty since plans generally do not end up being error-free. Others see a plan as a broken promise and nobody likes it when promises are not kept. Therefore: No planning, no broken promises.

This mental model needs to be reframed:

Imagine that you're climbing up a mountain. The path ahead of you is blocked and you need an alternative path to reach the top. What do you do? You pull out your map, look for alternative paths and decide on the best one to take.

The plan, while developing a software program, is your map. Not only is the plan a way to think through the details of your software in depth. It is also becomes the most valuable tool the minute you pinpoint a gap between your plan and actual reality: You pull your plan out to decide what the best course of action is to get back on track.

Triggering is the second reason for planning. The release of a software program entails far more than just pure coding. It involves a beta program, marketing and sales, i.e. non-coding activities. All activities must be in sync to reach the release date as soon as possible.

• As a manager, for example, I need to know
• When I have to have a private beta testing team set up,
• When the content for the website needs to ready,
• When the payment system needs to be in place,
• When the help and support documentation needs to be ready and
• When the press release must be published.

In software development, the coder sets the pace. The plan provides all non-coders with the right trigger to get their job done.

Now we'll get the right tools in place and guide you through all of the planning steps.

The toolkit should be as lightweight as possible: We recommend Numbers (or MS Excel) to list all of the software's features and to make estimates. All you need for GUI prototyping is a pen and a stack of paper.

You might tell yourself "I'm not a painter." However, you don't have to be a painter to perform GUI paper prototyping. By putting GUI prototypes down on paper, you think through your application's features in depth and it will take you less time than it would with any other tool.

You might say "But with pen and paper, I'll have to start all over again when I need to modify something." Yes, and this is for a good reason, too. Keep all of the different versions of your notes and occasionally spread them out next to each other to check the evolution (or revolution). Make sure to put the date and time on each piece of paper.

While conducting GUI prototyping on paper you will find out that some forms stabilize or are predetermined (like the iPhone's display screen). Make a stencil out of it. As an example, a link to an iPhone stencil is included in the reference section of this article.

This is how Cultured Code did it:

Figure 1: iPhone stencil by Cultured Code

What if you're really different: You deliver the best results by implementing them right away. Well, if this is the case, take the liberty to do it your way.

If your project is extremely complicated with highly complex dependencies use Merlin, which is the one and only project management tool that I would use in such a case. For all others (the majority) Numbers or Excel will do the trick.

There is one application specialist for software developers who work in remote areas: It's FogBugz. FogBugz is a bug tracker, project management tool and so much more; implemented by programmers for programmers - and not for managers. Since we now have a third team member on board (Michael discovered a great developer. Hi, Raphael!), we're now working in three different places and we set FogBugz up to update the plan, and it serves as a central hub for our seamless communication.

Now that our tools are in place, it's time for us to take action.

In essence, project planning is easy (often the tools or the method are what make it complicated):

First you need to brainstorm about all of your application's potential features, and then you need to list all of the features that must be in the first or next release and store all the rest for a future release. Finally, make sure to estimate the time it will take to implement each feature.

Secondly, update your plan. And that's all there is to it!

The first meeting for the planning session sets two main goals: The first is to get everyone involved to look ahead in the same direction and the second is to generate as many feature ideas as possible from as many viewpoints as possible: Go for quantity!

Get everyone who is involved in making sure the product is a success into the same room. It's the manager's job to get everyone to look in the same direction: Tell everyone a story dealing with the spirit of the soon-to-come software program. Then schedule a ten minute coffee break to get everyone to talk about it.

The first thing you have to do is to come up with some scenarios on how the user will deploy the soon-to-come application based on the "One day in the user's life" stories. Ideally, you should draw small graphics like a comic strip. Come up with two to five scenarios.

Then find real world metaphors users would apply in the scenarios if they had to do it without a computer. Image life without Google maps: Take a real map and some pins to mark the direction from San Francisco to Houston. In addition, the user might have taken some notes on important points to remember.

Resist the temptation to talk about "What will it look like in the software." That's something that can wait until tomorrow.

Document everything on a flip chart, whiteboard, post-it notes or whatever suits your brainstorming session the best.

After the brainstorming is over, it's the manager's job to document and structure all the ideas.

The next meeting on day number two will answer the question: "What will it look like in the software?" This is the right time to dig deeper and get specific. Don't be surprised if it takes you much longer than one day to finally answer this question.

And time for action: Take the first scenario and the real-world metaphors and jot down GUI paper prototypes to transform it into software. Take notes to describe the non-visible functions. If possible, do this with different groups of people who are working on the same scenario.

Compare the ideas and interlink the best ones. Once you have a lot of GUI paper prototypes, a pattern of features will emerge. That's exactly what we want. It's the first indication that it is stabilizing.

To get an idea of what a GUI paper prototype looks like, here is the one for Things for iPhone by Cultured Code:

Figure 2: GUI paper prototype, Things for iPhone by Cultured Code

Now do the same thing with all of the scenarios. Next, put the best solutions for each scenario next to each other for comparison. Again, check the pattern carefully and go for consistency: Buttons that trigger the same function must be in the same place and similar features should work in the same way.

One tip: Don't let a domain expert participate. Become a domain expert yourself and find your own solutions. For most non-software people it's almost impossible to imagine what things actually look like in software. Domain experts will come into play once you have a final-product-like-looking prototype.

Now it's time to decide which features to include in version 1.0. Put on the manager's hat and list all the must-have, super important features and set their priority to two. All of the nice-to-have features should be prioritized with a four or less. Et voilà: You have your feature specification.

You'll find some features in every good Mac software: Help, Icon, Website, Shop, Auto update, Serial number generator, Press release, ... put them on the feature list, too.

Now the ball goes back to the developer: Estimating how long it will take to implement each feature. To all the developers out there: Remember, you are doing this because the non-coders need to be triggered.

A personal note: Since you're not writing specifications for upper management, it's okay to have some fun. Name the user "Polly the potato." Write in a way so that your mom will understand the specifications, and not the compiler. It's typical to review and rewrite your specs several times.

Figure 3 (below) is part of the feature specs for our application:

Figure 3: Example for a feature specification

Here are some tips on how to write good feature specs:

• Write to get attention, and not to put people to sleep.
• Write to be understood.
• Write short active sentences not long or passive ones.
• Assign someone (and only one!) who is responsible for each spec.
• Describe only the invisible parts of the feature.
• Give every feature a title and a unique ID that never changes.
• If you use Pages or Word, make sure the whole document has a version number.

To find out more about how to write feature specifications, Joel Spolky's articles are an excellent source.

Rule of thumb: It takes three (!) times longer than you think.

This is why:

First, it takes a lot longer to implement a feature in a product because you need to get it ready for numerous exceptions to the rule. It's not like internal development where you can more or less coerce the user into using a feature in a certain way. Your customers will use it however they want and you must deal with their specific needs in a constructive way.

Second, getting the application released fuels your ideas further. Thus, your subconscious seduces you to underestimate the effort. That's okay it's human nature.

Be realistic and include the following in your estimation: you come down with the flu (five days each year), you take vacation (six weeks each year), time for debugging, and on the list goes.

Don't estimate features. They're just too complicated. Features consist of multiple functions. This is where the work for developers really begins: Thinking in great detail about which functions must be implemented to create a feature. In this way, developers think it over in great detail and they obtain an excellent baseline to estimate each function, before even starting to write one single line of code.

The scale estimation is in hours and not days or weeks. To all the managers out there: If you come across an estimation that is more than eight hours, ask the developer to rework it in sections consisting of less than eight hours. If an estimate is over eight hours, that definitely means the developer didn't think through it in enough detail.

To all managers: Whatever you think, the developer's estimation is authoritative. Period.

Inspired by Joel's famous Excel sheet for estimation, Figure 4 (below) is the one used for our application:

Figure 4: Example of feature and function planning

To find out more, read Joel Spolky's original and updated articles which zone in on estimations.

Quite likely, you've listed too many features for version 1.0. So now it's time to prioritize the features and decide which ones to incorporate in version 1.0.

The key rule: Features should only be ranked up to a maximum of priority #2. Priority number 1 is to be set for bugs and nothing else.

Take a close look at the scenarios and only rate those features with a priority #2 that are absolutely essential. All must-have features required by each application (incl. the user manual, support, updating service,) should be rated with a priority # 2 as well. Everything else should be prioritized between the range of 3 and 5.

Figure 5 (below) is a sample estimation sheet, including the prioritization.

Figure 5: Example of estimation and prioritization

Decision-making is almost always a hard thing to do. Even though the final outcome will simply be a Yes-or-No, you must nevertheless take your decision very carefully. Many useful approaches are available today on how to make the best possible decisions, however, you should only put one of them into actual practice. What works best for me is the approach crafted by Spencer - the "Yes-or-No Strategy." The following is a condensed version of the core components of his approach:

Step one: Avoid indecision and half-decisions based on half-truths.

Step two: After you thought deeply about your own rationale and have listened to opinions presented by others, you make a better decision and act on it immediately.

Step three: Is it necessary to decide and are you ready to do it?

Are you meeting a real need? - Is it a mere want or a real need?

Are you informing yourself about the options? - What information do you need? Have you come up with feasible alternatives?

Are you thinking it through? - If you decided on "x", what would happen then? And then what?

Yes or No?

Step four: Do you remain true to yourself?

Are you being honest with yourself? - Are you telling yourself the truth?

Do you trust your gut intuition? - Does it feel right? You weren't afraid?

Do you deserve more? What would you do if I deserved better?

Yes or No?

Finally: If the answer is Yes, act on it. If the answer is No, work through it again.

"Action is the last refuge of those who cannot dream" -- Oscar Wilde.

Do you feel a strong reluctance within yourself to list the features and estimations or to take the necessary decisions? If so, congratulations, this just goes to show you're in excellent mental shape. Procrastination is your inner shield that is there to help you sidestep failure. Nobody, of course, wants to see their all-out endeavors backfire and then ultimately fail.

What you do know is that to make sure your application is released, you cannot stop now. You must make feasible estimates, list the core features and take decisions, even when you run a risk of failing. The following are some ways that will help you succeed rather than fail:

1. Fully understand that something deep within you just wants to keep you out of harm's way.

2. Everything starts by taking the first step. So just do it! What you do doesn't have to be perfect. (I had to rewrite this article at least five times and in certain areas, revisions were made at least ten times. But that's how to do it and it does get done! Michael, for example, uses innumerable GUI prototypes to come up with the one that works best.)

3. Talk about it with others and ask for their help.

It's important to move forward everyday, at least a little bit. Taking a break intentionally is another way to move forward because you are tanking up on energy, reenergizing your batteries. However, if your break turns into a whole week instead of just a few hours, that could be a sign of procrastination.

An outdated plan is as useless as an old map. Keeping your plan up-to-date is a routine that you should turn into a habit at least once a week - and preferably once each day.

In this way, you will know when the triggers for non-coding activities are released and you will learn lessons crucial for the future.

Before unveiling version 1.0 on the market, it will not be a critically risky move to announce the release date later than initially planned because what counts, first and foremost, is that it is fully updated and really ready to go. However, once version 1.0 has been launched, you need to know when version 1.1 will be ready for release. You can be sure of one thing: People are only truly passionate about software that is updated on a regular basis (and with which YOU earn money for a living). Just take a look at the sales chart of VoodooPad in our last article and you will clearly see how sales dipped down due to the lack of regular updates. You need to trust your estimation.

Let's say it always takes twice as long as your first estimate (this is your estimation factor): In the future, multiply your estimation with that factor and you will be much more precise. Believe me: You'll love the feeling of being able to implement a feature on time!

Congratulations! That's quite normal and a sign that your creativity is in great shape, too.

When a new idea comes up while you're in working mode, jot your note down and continue to work. In this way, you stay focused and your mindset stays creative. It's not a vicious circle, it's a victorious circle - so take pride in it.

Don't think about your new idea for two or three days before you compare it with your existing ideas for version 1.0. In order to ensure adherence to the planned release date, you might need to exchange your new idea with an existing one.

But whenever in doubt, just stick to your original plan and save the new idea for a future version.

A decision log is simply a document listing all your decisions by topic, date of decision and description of the decision. Simple as it may seem during the development phase, it becomes super important later on and it's one of the very best time-saving tools.

You will have to take a lot of decisions right on up to the day when version 1.0 is on the shelves, and just waiting for buyers. In certain cases even after several months have passed, you'll find yourself confronted with a situation where you must make a decision on the very same topic again. Since you're smart, you don't waste any time by going through the whole decision-making process again. No, what you do is open your decision log up and quickly read about how and why(!) you decided months ago to take the course of action that you did. Now, all you need to do is to consider your decision in detail:

Do my reasons still hold true? If they do, it is okay and let's move on as planned.

Are new facts influencing your former decision? Ok, let's take another, new decision. As a consequence, you might need to update your plan and document your decision in the decision log.

In most instances, former decisions still hold true and re-reading them will save you a great deal of time rather than re-deciding all over time and again.

To be honest, we did not use a decision log at the start and we often regret not having done so right from day one.

Figure 6: Example of a decision log

Figure 6 (above) is part of the decision log for Aphorism inspired by Bob Walsh.

During the planning session, you made up your mind about all of the features you need to implement for version 1.0. You now know what lies ahead. When you check your plan today, you might even come across certain dates where marking a time to celebrate would be absolutely fantastic!

The closer you get to the release date, the more you'll consider your plan to be like an assistant that helps you to stay in control and to not forget something that is really important (like the press release). The plan will help you to relax and it will sooth your nerves.

If you implement a feature and you have to make a critical decision, the plan and the decision log will support you in taking the best possible decision in terms of the context in which your feature will be implemented.

Check your plan out: Are you or your team able to do it all by themselves? The GUI and Icon design, the coding, writing the user's manual, developing the webpage and crafting a press release that will spark potential buyers' interest?

Not all of us have been blessed with the gift of an omnipresent talent like that (I'm not). In our next article, we will tell you how to find the "Seven Samurai" who will help make your dreams come true.

If you're curious and want to find out more about the above-mentioned topic now, we highly recommend checking the "Seven Samurai" DVD out by Akira Kurosawa. The plot is the prototype of all modern action films and it's the metaphor of our next article.

We want to share stimulating, innovative ideas with you and we really look forward to your feedback! Is anything missing or do you think something could be fleshed out in further detail? Just let us know and write to oliver.pospisil@inspiredbylife.com.

Snyder, Carolyn. Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. San Diego, 2003.

Johnson, Spencer. Yes or No: The Guide to Better Decisions: A Story. New York, 1992.

Dan Roam. The Back of the Napkin. New York, 2008.

Bob Walsh. Micro-ISV: From Vision to Reality. New York, 2006.

iPhone stencil: http://www.designcommission.com/shop/iphone-stencil-kit/

Joel Spolsky on feature spec (Part 1 of 4): http://www.joelonsoftware.com/articles/fog0000000245.html

Cultured Code - Things for iPhone: http://culturedcode.com/things/iphone/

Merlin: http://www.projectwizards.net/en/merlin/

FogBugz: http://www.fogcreek.com/FogBugz/

Michael started MOApp up in 2004 and he has now developed more than ten applications - six of them are Apple staff picks. He does everything from software development, icon design, website development to sales management and public relations.

Oliver has been in the software business for over ten years, specializing in areas ranging from Palm programming to large-scale, in-house Java projects. In 2006, an idea grabbed his attention that both are now working on. He is still working full-time for a German retail company and will be until the new business starts paying off their bills.