Why We Don't Use Project Plans

Before we get started I will back some of these theories and concepts with our 8 years of experience, over 1,000 completed projects, 400+ clients and a rating of over 9.5 on the AppExchange. This style is not for every type of organization, but it does work.

GTD Principles

Anyone who knows Arkus, knows we are big fans and followers of the Getting Things Done® (GTD®) methodology by David Allen. We all read the book, talk about it, blog about it, and certainly podcast about it.  There is a lot to the methodology but the two concepts that we use in our project planning are the “Natural Project Planning” model and “Next Action Thinking.” The Natural Planning Model says to look at the outcome of a project first (Successfully Launch new Sales Team on Salesforce) but instead of trying to figure out all the little tasks that need to be done, boil it down to the Next Action (Schedule Kick-off Call). Once you have that done, do the Next Action or two (Get access to the Org and Set up Requirements Meeting). As long as you know the outcome and the next action, every little detail between isn’t as important.

Agile & Iterative

There are plenty of things that being agile and iterative wouldn’t work so well on, like building a bridge or baking a cake. There are some things that if you have to change your mind, go back, or update the process while in the middle, you might have to start all over again. You couldn’t have a bridge halfway built over a river and decide you want 5 lanes instead of 2. Salesforce development, on the other hand, is quick enough on a very flexible platform that changes can easily be handled almost throughout the project lifecycle. Since we welcome those changes as part of the Agile manifesto, as long as everyone is transparent and agrees on the new outcomes, we don’t want to get too bogged down in moving dependencies back and forth in a project plan.

Time & Attention

The final thing we consider in our projects is the value of Time and Attention. We believe that our time is very valuable both to our clients and ourselves, that is why we push back on time wasters like weekly scheduled status meetings and excessive onsite work. The more flexible we are with our own time the better we can handle our client requests. To that point, we believe that constantly updating a set of milestones, deliverables, dependencies, and tasks is just not a valuable use of anyone's time. That time could be better spent actually moving the project forward by doing the work, not just documenting the steps of the work done.

Sometimes (But Not Always)

All that being said, there are times when we do plan out a project in more depth. If it is a much larger project, with lots of moving pieces, it is a best practice to just jot down some high-level buckets of time, either by week or month, with a few high-level items to be accomplished in those buckets. We will review this at the start of the project and maybe check back when halfway through to see where things are. Again, business and requirements change so fast, that constantly changing that data is really just a waste of time.

Those are our project planning best practices, what are yours? Throw some comments below, in the Success Community or directly to me at @JasonMAtwood.