How to Get Started on a New Business Strategy Project - dummies

How to Get Started on a New Business Strategy Project

By Marina Martin

The start of an execution plan for a management change or business strategy change outlines the information you already have in hand regarding the project, the reasons for the project, the desired results, and your assumptions about how you will handle the project.

State the problem

If there’s no problem, then there’s no project. Write down the problem or inefficiency that the project is aiming to address.

Include specific details here to make sure you address the entire problem in planning and executing the project. If you leave out a requirement, then your final solution will not be as efficient as it could have been (and will result in a brand-new project).

Clarify your end result

What does the ideal project outcome look like? Describe it in detail here, using the problem statement as a guide. For example, if the problem is that current equipment is down 20 percent of the time, then the desired end result may be a zero downtime during the three months after installation of new equipment.

In Agile Project Management, this step is known as writing a user story — an actual story of what it looks, sounds, or feels like when the end customer is actually using the expected finished product. At the end of a project, you reenact this story to see if it plays out as written.

Identify your constraints

A constraint is any limit — chronological, financial, scientific — placed upon your project. Typical constraints include budgets, an external due date, the skillsets of your team members, and the number of hours available in employee schedules for new work, or lack of support from senior management and leadership.

Every project has constraints, and your end definition of success needs to take them into account. If you have a $500 budget or no more than two hours a week to put together a new corporate website, then three pages of text and a basic design template may be all you can achieve. This same outcome would not be considered a success if you had six months and a team of four full-time employees to design the new site.

Outline your assumptions

Every project manager has certain assumptions when going into a project, and it’s an excellent exercise to become aware of those assumptions and commit them to paper.

For example, you may take it for granted that the internal legal department will handle your project’s contracts at no additional cost. This may be true, or you may discover later that one contract requires a specialized type of law that your internal resource cannot handle without outside, paid help. You may account for some of these assumptions in your risk planning, or they may prove informative to a future project owner or participant.

There’s no need to go crazy here — we all know you need oxygen and the business to be open for the project to succeed — but generally every time you think “that’s not important” or “they’ll just take care of that” in the course of project planning, you should add that assumption to the project plan.

Acknowledge your risks and uncertainties

Some project outcomes are riskier than others. Risks don’t mean you shouldn’t forge ahead with your project, but you do need a contingency plan if one or more of those risks comes into play. It’s always better to plan for acknowledged risk up front than to assume you will just be able to address it if it comes.

For example, if a new law might add new compliance requirements to your project, this poses a risk to your timeline. An efficient execution plan would include steps for addressing these new compliance requirements and an amended milestone list.

There’s no need to outline risks that apply universally. Yes, your project manager can die or float away during the Rapture, but that can happen to any project. Instead, list risks or uncertainties affecting this specific plan.

Secondhand knowledge is also an uncertainty. If your project relies on details that you or a trusted team member did not supply yourselves, these are uncertain until further researched. For example, if a salesperson you meet at a conference verbally tells you how much her software costs, this number is uncertain until you get a formal, written quote from the vendor.