When does a Project Start

Author: Neville Turbit

Overview

Many projects seem to float into existence. Ask yourself when your project started? Can you honestly answer? There may be a date on a schedule somewhere but that only reflects when the planning hit the paper. As with most projects there is an idea in somebody’s head which gradually gains momentum until we have a project on our hands. At that stage there is probably a bit of a scramble to retrofit some rigour to the process.

When does a Project Start

It is hard to get an exact definition. My personal list of things that should be in place are:

An almost clear idea of what the project is about
Agreement from the organisation that this piece of work is probably worth undertaking
A nominated resource to undertake the work
Funding available, or at least seed funding

An Almost Clear Idea

Some might argue that the scope should be crystal clear before a project starts. I have found that the only time to get a crystal clear point of view is just after the project finishes. Even then, it is more about what was delivered outside of the scope rather than what is in scope. Scope goes through varying degrees of clarity.

Part of project management is to both define the scope, and get agreement on the scope. Typically a project starts off with several people having a different view as to the scope. Sometimes it is lack of communication; sometimes it is an attempt to hijack the direction. A hijack may be for positive or negative reasons, but until a project scope is agreed, it cannot really move forward. Quite often, there will be considerable effort expended in getting the scope agreed. If this is carried out before the project is formally initiated, it provides the opportunity to back pedal when a team is formed and new people try to pick up where some others left off. That is why I am prepared to accept the “almost clear idea”. Once the team is formed, it can refine the idea and remove ambiguities so that it is clear.

Agreement that the Work is Worthwhile

In many organisations, there is a review process where a number of projects are proposed each year, and only a handful accepted for actual implementation. Should a potential project be initiated as a project prior to approval? My answer is that the prioritisation process is a project in itself. It has a beginning and an end (when the prioritisation is complete). The deliverables are proposals for projects, and a list of projects to be undertaken (or not undertaken). Once the prioritisation is complete, the “Prioritisation Project” is closed, and a number of other projects initiated. These new projects take the output of the “Prioritisation Project” as input.

If there is no formal process, it does not make sense to begin a project unless the organisation is likely to support the project. Once you formally begin, and allocate resources, the project starts to build a momentum of its own. It becomes harder to stop if the organisation suddenly feels it is going down the wrong path.

So how does an organisation decide it is worth undertaking? Typically it must

Align with corporate direction
Be affordable
Show promise that it will deliver a benefit
Be within the capability of the organisation to complete successfully

If it meets all these criteria, it will probably get a start.

A Nominated Resource to Undertake the Work

I have said a nominated resource rather than a Project Manager. It may be that a Business resource is assigned to get the project started and in the process will appoint a Project Manager. It may also be the Project Manager who does the first stage, will not continue on the project. A different set of skills may be required, or it may be that the organisation has a Project Manager who is a specialist in initiating projects. They might then hand over to another PM to manage.

If there is no nominated resource, it can fail most of the criteria for a project. No schedule; no deliverables; no end date; no roles and responsibilities. It just becomes a chunk of work we will fit in when we can.

Funding available

Unless there is some money to allocate to the work, how is it going to be done? If someone is doing it on top of their day job, it is hardly a project. If the organisation is serious, they will allocate some funding to either do the whole project, or at least develop a plan and a cost. The money does not have to be a specific budget allocation. It may simply be that out of a normal operational budget, a department may allocate one person for a period. The funding is more a financial commitment from somebody to subsidise some work.

Why is it Important to Create a Project

A project has an entirely different connotation to the business than a piece of work. Going back to basics, a project has:

A start and an end
Delivers something of value to the business
Has allocated resources

A “piece of work” may have no beginning or end. It may not result in a benefit to the business. It may not have allocated resources. It is just a variation on “business as usual”. In other words, it is low priority. It gets done when there is time available. A project on the other hand is going to deliver some value, and is going to complete by a certain date. A project provides an element of accountability that a “piece of work” may not. Becoming a project formalises a “piece of work” and makes someone accountable for delivery.

It also creates a different mindset. Suddenly it brings in things like schedules and risk management. It raises issues of cost management and control. It focuses people on defining scope and deliverables. It implies the rigour of cost benefit analysis.

A Case Study

I was working with an organisation recently that had a number of business projects. One manager told me he did not have a project. It was just a chunk of work. When I dug deeper – but it didn’t have to be too deep – the work was obviously a project. As it was not organised as a project there was little visibility of progress or timelines. In fact, the attitude was very much:

“Where did we get up to yesterday, and what will we do today?”

The sorts of problems they faced were:

Inadequate resources because there was no schedule of work to resource
Different expectations across the organisation because there was no agreed scope
Constant unexpected setbacks because there was no plan and no risk management (plus no clear scope of course)
Deliverables constantly morphing as each day took the project in a slightly different direction
Lack of management support because the executive team only had a dim view of what the work was all about

There was strong resistance from the manager running the pseudo project to not formalise it. He just wanted to keep going along the path he was without all that “bullshit” project stuff. The key that I finally found was the resource issue. By producing a project plan he was able to go to the Executive and show them the people he needed to get the work done – ergo a schedule. In fact we did a few options with different resource levels.

Once he had the resources, we used the schedule to focus the new people on deliverables that illustrated to management that the project was in fact making progress. The manager was using a schedule to get people off his back because he could now say something like

“We will have a report with recommendations for you by the end of the month.”

That led to clearer understanding from management. One of his managers told him he didn’t want recommendations. The manager undertaking the project was responsible for deciding on changes and implementing them and didn’t need to get anyone’s approval. Naturally when I heard this I made the point about how responsibilities should have been defined early on.

Another question about deliverables was what benefit they would provide. This caused a workshop to be held where benefits were identified and committed to by different departments. When the combined benefits were presented to the Executive team, suddenly the value of the project was evident and it gained a much higher profile and improved level of support.

In the end, we turned it into a project, and the manager became a hero. The frustration he had experienced when I first spoke with him was replaced with a successful, high profile project that did his career no harm whatsoever. I was amused when he rang me after the project was completed to tell me that since he had done such a wonderful job, the company wanted him to head up a large project in another business division.

The First Step

There is a logical point to start a project. Provided the idea meets the criteria we mentioned which were:

An almost clear idea of what the project is about
Agreement from the organisation that this piece of work is probably worth undertaking
A nominated resource to undertake the work
Funding available, or at least seed funding

The first step is to define the scope. We have an “almost clear idea” but often it is different depending on who we talk to. The differences may be in the detail, or they could be fundamentally opposing points of view. These need to be resolved before you can understand things like:

Timing
Resource requirements
Cost
Risks

Defining Scope

The starting point for scope is to define the stakeholders. Once you understand who these are, there is usually one person who is the initiator of the idea. It may be a department head, or it may be the person who is going to pay for the project. It may be a technical specialist who raised the idea. It may even be someone outside the immediate area who wants to make their own role more efficient by having another area clean up its act.

Start by talking to the Business Initiator. Get their perspective. Ask them about existing information that may exist, and verify the other stakeholders. Try to get an understanding of the existing support or opposition to the idea.

Four Questions

In another white paper we cover how to start a project. There are however four questions to ask key stakeholders.

What is the project setting out to solve and what will it deliver
How will we know if the project was a success
What do you see as your role in the project
Are you prepared to commit resources to the project

The other white paper covers these issues in depth but you need to touch base with all the key stakeholders and ask the questions. If there are differences they need to be resolved. Only then can you define the scope.

Conclusion

If you are involved in kicking off a project, remember the four criteria.

An almost clear idea of what the project is about
Agreement from the organisation that this piece of work is probably worth undertaking
A nominated resource to undertake the work
Funding available, or at least seed funding

Get these in place then kick off the project. Focus on defining scope then you can put together a project in a controlled structured environment.