Ask HN: Does a perfect plan increase the chances of success or a partial plan?

I think every project needs some kind of plan but how elaborate of a plan depends on the project.

I had a setback in my career because of a project that failed because there wasn’t any project management. I joined the Project Management Institute and was thinking of getting a certification so I studied that PMBOK which lists just about everything that might have to be managed to manage a project including hiring people, communicating with the public, etc.

I think the most common problem people have with side projects is that they get a huge number of ideas and do a little work on a lot of them and make no real progress. That is where the Kanban thing comes in. The idea is that you limit the number of things you have in progress. You will see this principle at a cafe where they will only take your order when they have made sufficient progress on other People’s orders (e.g. they will process more than one order at a time because they have to wait for the oven to finish)

Most of the time I have three side projects I am committed to, usually I am making real progress on two of them and the other is aspirational and I am not really making progress on it. Maybe sometimes it moves to the fore or I give up one and start another. It is not perfect but I do complete projects so I am happy with this.

What you need to do is have just enough structure to deal with the problems in front of you…. If in the other hand you really want to learn project management it is a worthy subject with a lot of resources like the PMI.

http://www.poppendieck.com/reference.htm - a lot of good books, don't bother reading them all. It's listed in reverse chronological order, I'd read some of the older ones first. I'd add Deming to the list, Out of the Crisis is a tragicomic read because you'll realize that we haven't learned anything as an industry since he wrote it (published in 1982).

OK, so I have a lot to write on this topic but I'm going to distill it to just a few points.

1. Don't create longterm plans, period. If you do, they should be no more detailed than a sketch past the 3-12 month mark (where in that period depends on your context). And it should never be treated as a commitment, because there are too many unknowns. Even if you fall for the idiocy of BDUF for a large effort, your design will almost certainly be wrong unless you've done the work before (in which case why are you designing anything, you have a design already; no, wait, why are you building anything you have a working system).

2. If you don't know how to judge whether a plan is good or not, then create the opportunities for yourself to learn. Either read about successful and failed projects, or go participate in many projects, or go observe them. If you're in a corporate environment you should have the ability to do all three of those.

3. If you have one big project you need or really want to do, and don't have the time to broaden your experience across many other projects, then be smart. The only smart way to run a large, complex, longterm, novel (to you or industry) project is iteratively. Iterations create learning opportunities because they offer you a feedback loop. Learn from each iteration and revise your planning practices and plans as you go along. 12 month iterations mean slow feedback, so use smaller iteration cycles (1-3 months, maybe 6). You don't have to deliver a deployable product each iteration, you need to deliver something that can be learned from though. Even prototypes to solicit feedback from customers or a proof-of-concept that can determine the next steps (possibly even ruling out the approach taken in the POC) are fine.

4. Avoid large batch sizes. Don't turn in a complete rewrite of a system after 24 months of work and hope it works. Find a way to incrementally deploy or deliver the changes. One of the worst projects I worked on required 3 successive generations of the system to be running at the same time because each generation was a big-batch, BDUF project. By the time they were finished they didn't deliver features that had been added to the older systems. Oops (not oops, it was obvious it was going to happen to anyone who thought about it). Delivering smaller batches or transforming the existing system is the most reliable way to succeed on a large effort.

5. Learn the difference between "big step" and "little step" work and how to judge when each is appropriate. This can be approximated with iteration lengths. If you have a lot of unknowns, you want shorter iterations in general. This gives you more feedback earlier to guide the next steps. When you reach a point where you know the next steps, you can increase your iteration sizes and scopes. Accept the risk, though, that goes along with that. A 12-month iteration that fails means you have to potentially rollback 12 months of work. A 1-month iteration that fails, you lose 1 month of work. When is frustrating, the other is catastrophic and potentially destroying your business.

In case it's not obvious, the common theme is iterate, learn, and adapt. You have to iterate to reliably succeed in novel large scale systems development. Complete plans spanning large periods of time become binding obligations because if you spend $1-10 million creating a plan, you or your paying customers will want (sunk cost fallacy coming into play) to see the plan through even when it becomes obv...