The idea “begin with the end in mind” comes from The 7 Habits of Highly Effective People by business leader Dr. Stephen R. Covey. However, starting with the end—or your goal—in mind is as applicable to the effectiveness of projects as it is to the effectiveness of people.

The “End” of a Project

The “end” of a project is the expected outcome or the objective. What is the project trying to accomplish? What problem is it trying to solve? For product development, the “end” is the expected feature set of the product and what those features are intended to accomplish. For development, the “end” is the function(s) the software, code, or service will perform.

It sounds simple enough, but to achieve objectives successfully, a lot of planning needs to go into defining goals and into determining specific needs before anything else begins. Time and time again, projects fail—or take much longer, and cost more than needed—because participants didn’t want to plan ahead. Why? Because planning is hard. It’s intimidating. It can seem easier to just start and hope you’ll find a path along the way. Planning ahead also often involves that “dirty” word “process,” which strikes fear and dread into the hearts and minds of many who hear it.

I’ve seen some poorly planned projects come off much more successfully than I thought they would. That success, though, was accomplished with a lot more stress than was necessary to achieve it. I’ve also seen beautiful outcomes achieved with much less stress when planning and a little process is involved compared to when it’s not.

In Defense of Process

I started my career as a writer at a technology company later acquired by 3Com, a now defunct leading hardware manufacturer of computer networking products. After years of wrangling internal clients, my manager had developed a rock-solid process for moving projects through the pipeline.

My manager left when 3Com acquired the company, but the stamp of her beautiful process lived on. Our small four-person team was so proficient (and talented) that we moved four times more work through our project pipeline than any other team in our department. I’ve taken that process and adapted it at many other employers with great success.

Interestingly enough that success was not always easily won. Process is too often a “dirty” word for people it seems. The “p” word as I sometimes call it often invokes an instinctual grimace the minute it hits a recipient’s eardrum. Consider though that the first synonym Webster gives for “process” is “course.” If you consider process a dirty word, perhaps instead of asking, “what’s our process,” you should ask, “what course are we going to follow to get this done?” Consider also that the common values from the agile manifesto that start with “individuals and interactions over processes and tools” go on to outline the scrum methodology. “Method” is yet another word for process—it’s the process underneath the scrum that allows the individuals and interactions to come first!

With and Without Process

Let’s look at two different scenarios for taking your car in for its 75,000-mile service. In scenario one, the mechanic follows a fairly typical process:

  1. You check in at the desk, give the service manager your key, and agree on the maintenance to be performed.
  2. Your partner drives you home.
  3. You receive a call that your car is ready a few hours later.
  4. Your partner takes you to pick up your car.
  5. You go to the cashier and pay for your service, and then you’re on your way.

This works without a hitch. It’s the same basic process every time you go in. Once your car is checked in at the desk, an order is kicked off, a mechanic assigned, and a series of alerts in the computer system moves your car through the service queue. The service manager is alerted when your car is finished so she can call you and send the bill to the cashier.

Now imagine scenario two at a different mechanic. He’s a bit more ad hoc. Your experience looks like this:

  1. You check in at the desk, give the service manager your key, and agree on the maintenance to be performed.
  2. Your partner drives you home.
  3. At 5:00, you call the mechanic because you still haven’t heard from him and know he closes at 6:00.
  4. The mechanic apologizes and tells you that they didn’t get to your car and will need it another day.

This mechanic doesn’t have a process, or at least not an effective one (though his approach could be considered a process of sorts). He simply takes cars as they come in, guesses how much time each will need, and sometimes forgets about cars along the way. His approach makes his work day chaotic and his employees unhappy, and it results in a lot of dissatisfied customers. His end in mind is to work on cars. The only planning he did to open his business was to buy a shop and the needed tools and supplies.

Mechanic one’s end in mind is to move customers through the service queue as efficiently and effectively as possible in order to maximize efficiency, cost, and the customer experience. He and his team put extensive planning into achieving this objective. They outlined a business plan and outlined what they want the customer experience to be and what supporting technology, in the form of a queue-management system, they’d need to get there. They identified what capabilities the system must have, which ones they’d like but could live without, and so on. They took their needs to prospective providers of queue-management systems to ensure the provider could meet their needs. It was a sometimes-arduous process, one they revisit as new features and capabilities become available and new needs are identified; however, they are highly successful and efficient.

The point of this analogy is that the success of any project is greatest with planning and a process. Development projects use scope documents and scrum meetings, product managers use product plans, and marketing projects use marketing or creative briefs and timelines.

The Course of a Prowess Project

For Prowess, the “end” is what the Prowess team and our client are trying to accomplish, what problem the end deliverable will solve for the client. This is true regardless of whether the end deliverable is a white paper, benchmark testing, demo development, or online journalism.

After initial discussions between the client and one of our account managers, we officially start a project with a kickoff call where the Prowess team (typically the account manager, project manager, writer, and designer) gather information about the client’s needs and goals, review our typical project process, and agree to adjustments if needed. Information gathered on objectives and our recommendations are then distilled into a marketing brief that we include at the top of each milestone’s deliverable. The brief outlines what we’re creating, the target audience, and as much information as we can include about that audience’s mindset, the project’s objective, and a relevant call-to-action, if applicable. We encourage clients to review the brief each time they review a deliverable and to ensure with the initial deliverable, typically the outline, that the information in the brief is in line with their expectations.

Generally, Prowess projects include a content outline and design concepts if applicable, first-draft content, second-draft content, final-draft content and template design, and the final deliverable. Once a project is approved as final, source files are provided to the client. Shortly after the kickoff call, your Prowess project manager will send you a timeline with dates for each deliverable and the deliverable’s review cycles.

Get Ready for Your Next Prowess Project

Next time you kick off a project with Prowess, consider the following questions in advance. You don’t need to have all the answers—we can help you nail them down. But when you come to your kickoff call having thought about these questions, it will help us help you ensure your project achieves maximum success.

  1. What are the objectives of the deliverables?
    • What business problems/needs are the deliverable trying to solve?
  2. Who is the primary audience for the deliverables?
    • Under what circumstances will your audience encounter the deliverables?
    • What does your audience care about?
      • What are your audience’s pain points/key triggers?
    • What do you want the reader to do after seeing the deliverables?
  3. Are there any secondary audiences for the deliverables?
  4. What are the three key messages for the deliverables?
  5. What makes your product/solution unique? What are your product/solution’s key differentiators?
  6. What are the strengths, weaknesses, opportunities, and threats for your product/solution?
  7. How will your measure the success of the deliverables?
  8. What is the desired call to action for the deliverables?
    • What do you want the audience to do after seeing the deliverables?

Until your next project, follow us and our growing communities on the Prowess Consulting Thought Lab blogLinkedIn, and Twitter.

Share this: