Reading Time: 4 minutes

In last week’s blog, we discussed project management processes, and why you need them. If you haven’t read that blog, I’d suggest you start there. In PMBOK terms, there are five processes and today we cover the first one – initiation – or starting a project. Starting projects wisely will save you time and money over the long-term.

The beginning of a project can often feel like one of two very different scenarios. Either, the project gets communicated to the team with enough clarity that energy is high and everyone seems committed to the goal. It can be tempting for these project teams to skip the beginning basics, often because this scenario typically occurs when project teams have done similar projects and the tendency can be to just follow a template.

Or, it starts off in a vague, ambiguous way that leaves the team feeling confused and perhaps a bit unqualified. This latter scenario applies more often to complex projects where the team is trying to do something it has never done before.

Regardless of the type of project you are undertaking, try these six steps for starting projects wisely to improve your results. While project work can be iterative, these steps should be mostly finished before you get into scope definition and begin to tackle the planning process.

Define the overall objectives so that your team is energized, excited, and empowered.

Regardless of whether this assignment comes from a client or your management team, the first step is to understand the overall objective(s) of the project. At this point, we’re not focused on the details of scope planning, but rather, the high level objectives. Even though you will often have no idea what the project details are, try to clarify the objectives.

Try to write the objective so that it clearly and compellingly identifies why you are doing the work. Defining ‘why’ you are doing the project in a compelling way will keep your teams energized as the challenges of project execution arise.

Determine what is important to your client (or management team) so that you can make better management decisions.

You can have it fast, cheap, or well built, but you can’t have all three. Contractors have known this for years, but the business world often forgets. In my work, there are other factors that may be important. Some businesses, for whatever reason, are risk adverse. It may be as simple as a downtime issue. Whatever the project is must be done without downtime.

Well built is a relative term. Different people will have different understandings of what that means. For now, simply prioritize the most important factors for your project, with the factors being cost, schedule, scope, quality, and risks.

Identify risks, issues, assumptions, and constraints so that you can strategize appropriately in your planning process.

How many times have you seen a team get into project execution before they discover that one of their assumptions was flawed? You need to begin by simply understanding what your risks, issues, assumptions, and constraints are. Write them down. For now, don’t get too bogged down in the nuances. Simply identify all of the potential problems that you can see on the horizon.

Document measurable success factors so that you know how many people to invite to your celebration party.

Ok, I’m kidding. But you do need a way to look back at the end and understand whether you were successful. So often I see teams undertake projects with an insufficient understanding of what constitutes success. For example, suppose you’re leading a consulting team, hired to assist a product design firm review and improve its compensation structure. As you get into the project, it becomes clear that the management team is hoping for higher bonuses. Yet your firm is aware of considerable evidence that bonus systems can reduce creativity. As you present this evidence, an impasse arises. What do you do? This is a good example of a situation where the team will benefit greatly from understanding what constitutes success.

Understand failure criteria so that you don’t wind up stranded in that swampland.

One of the popular mantras in the start-up world is to fail fast and fail often. I understand their logic. We have to take risks to conquer new territories. But so often, I wonder if some of these costly failures could have been avoided if the team had understood more about what was needed and not needed. I’m not suggesting that we don’t move forward until we have certainty. But, maybe the mantra should be to fail small and learn fast. It is just not prudent to waste investors’ money on failures that shouldn’t have happened.

In the Smart Projex community, we talk about the smart start. As a project lead, you have more human capital at the start than you will when things get tough. Use that capital to ask some tough questions in the beginning and get those answers down on paper. Ensure that people agree on the basics before you sail into uncharted territories.

Disseminate a signed project charter so that your teams are authorized to begin work.

The start phase of a project finishes with a signed project charter. There are different opinions about what a project charter should include. The challenge is to find that sweet spot between something that allows the project to morph appropriately and yet, provides enough structure to help teams understand what the project is all about. At a minimum, the charter authorizes the project to begin, defines the general objective(s), announces the project manager, and asks for support. You can read more about project charters here.

Want more tips? Sign up for our newsletter. And stay tuned for part three, Five Project Planning Steps to Boost Your Results, next week.