Plan, We Don’t Need No Stink’n Plan

Out of all the things a startup should do, planning seems like the last thing on anyones mind. Maybe that’s because once the first shot is fired, that pretty OmniPlan Project schedule becomes rapidly worthless. Worthless in the sense that your nice linear plan will never reflect the non-linear nature of your startup. Now, you may be thinking, why bother scheduling? The reason is simple: without a solid understanding what you need to do, you will never be able to adjust, align, change or modify your direction. Another important reason: no one will fund you without some sort of rational plan.

You Can’t Change a Plan Till You Have One

Scheduling innovation requires a pragmatic sense of what is achievable coupled with an understanding of how to push your group without breaking them. Being reasonable and rational about schedules starts with understanding what needs to be done and planning the tasks involved in achieving your objectives. Pretty simple really but hard to actually do since most people just want to get working. So, here’s the process I use to schedule innovation even though I know that once I start, most of the plan will rapidly becomes stale or change:

1. Think in Terms of Effort Not Duration: The duration of a task depends on the effort required and the resources applied. If you only think of duration you completely miss that resources are not equal and dependencies affect duration.

2. Break The Design Into Functional Units: Functional units are a great way to dissect a project into its component parts. This also allows some level of parallelism once you sort out the dependencies.

3. Figure out the Dependencies: All project has dependencies. Sorting these dependences out will give you a leg up when the project goes down a path that requires changing things.

4. Assign Resources: All resources are not created equal. Some will have different working times while others will be based on some manufacturing process. The trick with resources is to set the working time correctly so that it reflects the actual amount of effort a resource can apply during the week. For scheduling purposes, never book a resource longer than a normal work week. It will just lull you into a false sense of security since things will change.

5. Analyze the Critical Path: By definition, there is one and only one critical path in a project. It is defined as the longest duration path that your project follows. Put another way, the critical path is the series of interdependent tasks that have zero slack, where slack is defined as how much time you have before the project ends to finish a task. Once you understand the critical path, you need to closely watch it since most likely, it will change.

6. Use KPI’s to Monitor Progress: Key Program Indicators (KPIs) are micro-milestones that show you how well you are getting things done. The nice thing about KPIs (as opposed to percent done), is that they represent actual things getting done. This monitor will show you how well things are progressing and will allow for adjustments when necessary.

7. Don’t Fall In Love with the Plan: A lot of times, entrepreneurs stick with a plan or project even when it’s clear change is required. In fact, the plan will change. You will end up throwing away or reworking a lot of your plan anyway. To top it off, as a monitor of progress, your project plan is practically worthless. It’s better to just realize plans will change and use your planning as a way to thrash out issues and constraints.

Been There, Done That

I can image that many of you are skeptical about this method since your schedules never slip, you never miss a feature, never get surprised or have an infinite bucket of money. For the rest of you, here are a couple of examples that prove my point. One where I didn’t follow my own advice and another where I did.

Example 1: I Hate Demos

One of my many character flaws is that I think demos are a waste of time. I know, not a good attitude to have but it has been deeply beat into me. I have started demo haters anonymous and am making steady progress.

My present company needed a demo to show investors and I was charged with sorting out the plan. This demo had to show that our technology worked and could be scaled to a pilot and then to a release. The time frame was short so the team dove right it.

Mistake #1: Duration is not the same as Effort

Foolishly, I committed to get this demo done in a couple of weeks. This was without any plan or list of what had to be done or what the demo had to be. My thinking: How hard could this really be? I mean, heck, we are working on the product and most of the pieces are available. When you dive in without a plan, all those assumptions you make, you know, the “that will be easy” or “we just have to do this” will turnout to be false. These false assumptions will create more work and slip your deliverable. I grossly miscalculated the effort and the duration expanded.

Mistake #2: No Plan Distracts Resources

Without a solid plan, the resources I applied to the demo were inefficient because they were distracted on figuring out what to do. We were doing engineering on the fly and that led to a lot of rework and wasted effort. This led to the team being inefficient and expanding the duration of the work. The effort to get the job done was the same but the rework (due to no plan) was killing us.

It’s Never too Late to Plan

After our rocky start, I decided to step back and plan the demo effort. One thing I should mention is that this demo has lots of moving parts. There is custom hardware (an RF front end, FPGA, etc), embedded software (that drives the RF front end), GUI software (so you can see it doing something) and a box (so it looks neat and clean). All of these parts need to come together and depend on each other. Once the plan was in place, it was a lot easier for people to help out and to see the dependencies. Resources could focus on specific tasks and it got done.

Example 2: But I Love Products

By now, you have probably figured out that I work on system solutions instead of pure software. This means that a lot of different pieces parts need to come together in order to ship something that a customer can use. These pieces usually consist of hardware (chips, embedded systems), software (both application and embedded) and mechanical (wiring, antennas, boxes, etc).

Hardware without Software Creates Expensive Resistors

As you can image, systems projects have a lot of dependancies. If you don’t map out these dependancies you can waste a lot of time and money waiting around for things to get done or reworking. One particular project where careful planning saved my hide was sorting out the hardware and software dependancies on a chip development project.

Success #1: Is Anyone Working on the Software?

Nowadays, most chips need software to function and have some sort of development kit to assist in building applications. These two pieces are an essential part of releasing a product. If you don’t have the software ready when the chip comes out, then you lose precious time and waste a lot of money. Luckily, the plan I came up with accounted for this and when we got close to our “software needs to start now date”, I asked a simple question: Who’s working on the software? Stone silence. Not good but recoverable since I planned for it.. Without that dependency modeled, the chip would have come out and no software would have been available.

Success #2: Knowing the Critical Path Switched

On this same project, there had a real nasty block that was in the critical path. The team beat on it and beat on it until they had a major breakthrough. Once that happened, the critical path shifted to another block that was actually behind. Realizing this allowed me to re-plan parts of the project and then focus on the new critical path. Without the detailed plan, I would have been lured into a false sense of being on top of it.

More Art Than Science

Project scheduling is more art than science. Schedules often slip even though you have ground through all the details. It’s important to have a detailed plan but to also remember that when the project starts, you plans will change. It’s critical to be prepared by at least having a plan you can change.