A Basic Guide to Project Initiation

Setting Up for Success

I keep hearing of business projects failing where the post-analysis seems to focus on what happened during the planning and execution phases. However, in my experience and opinion, many project failures trace their roots all the way back to the point of inception. When you plant a garden, soil preparation is often more important than the seed itself. This is the same for good Project Initiation, ensure you have a well prepared environment in which to grow your Project.

So in the interests of improving Project Initiation I want to share a few areas to consider when you’re thinking about your next project. The checklist approach to Project Management is a weak method, so instead you should view these points as your initial step into Risk Management. If you discover that any the following items are missing or undeveloped then your Project is already presenting negative risk and this highlights potential points of future failure. That doesn’t necessarily mean you must stop your project, but any absent or deficient items must be remedied or managed appropriately (read: risk management).

This is not an exhaustive list of considerations, but my experience shows that these are common items which are easily overlooked or simply assumed, and assumptions must always be validated!

Project Sponsor or Project Executive - Committed & Engaged

This role is the most critical, especially in the early days. This person owns the overall accountability for the project. This is the person who accepted a business need and was willing to support the next step of turning that need into a project to deliver business benefits. They must be committed and engaged otherwise the project has a high chance of running into insurmountable roadblocks or going off course right from the start. This role cannot be delegated, shared or delivered by proxy, it must originate and remain with someone who has the appropriate level of authority to drive the project forward. You’re not yet at the point of having a Project Board or Steering Committee, they appear later on; so for now the project will rely heavily upon this crucial senior role.

Business Case

In short, the Business Case supports and justifies the very existence of a project. Quite bluntly, without a Business Case your project has no right to even exist. I always think of the Business Case as being like a lighthouse which is a fixed point of reference to keep you on course. Without a Business Case you will find it almost impossible to prove what you were aiming for and if you’ve achieved it yet. Furthermore, the Business Case is the original, high-level baseline from which Change occurs, and Change will occur. However, a Business Case does not need to be a massive, detailed document. A Business Case must exist, but it must also be fit for purpose, so perhaps even a few pages will suffice.

Stakeholders

Ensure you know who they are and that they understand they also have responsibility to support the project’s success. I find it best to meet with each Stakeholder, where possible, and begin the Change Management process, setting expectations in both directions. Your Stakeholder group may also determine who will sit on your Project Board or Steering Committee, so begin early stage assessment of who is most suitable for these steering roles at the same time.

Change Management

To be clear; this function is about Organisational Change and not Scope Changes or Software Releases. I believe this role is often filled far too late. Whilst it is not always required, when it is necessary it needs to begin engaging far sooner than most people appreciate. There are often far reaching impacts across organisations, even extending beyond their walls and into customer, supplier and partner environments. Given the nature of technology these days, everything is connected and, therefore, the ripples of change reach further than they used to. Change will occur and change must be managed.

CARD

This is an acronym for Constraints, Assumptions, Risks (Issues) & Dependencies. Right from the outset it is advisable to begin a Project Register to capture and manage these items. Have a brainstorming session with Stakeholders and anyone else who may have been involved in previous projects around the same subject matter. Take my advice, if you can’t find any CARD Items then you’re not looking hard enough! There are always items to capture under each of these headings. Even if you don’t discover them, then they will find you soon enough. Remember; every CARD Item will impact the project, each one will affect the primary factors in some way, and by primary factors I mean Time, Cost and Scope.

• Constraints: Discover current and projected Constraints including availability of all critical resources. Consider; time, weather, laws, budget, technology and anything else which is relevant to your delivery subject.
• Assumptions: Projects are littered with Assumptions, especially at the start, and that’s OK. The key to Assumptions is having them validated, so capture them and ensure they are assigned for someone to validate, although this may occur later in the project lifecycle. Ideally, when you begin the Delivery Stage you will have no remaining Assumptions as these then generate additional Risk.
• Risks & Issues: Risks are simply Issues that haven’t been realised, so I tend to manage them together. It’s your choice how you do it, but you must manage risk in some way. Have an early, big-picture risk identification session and then review regularly. Risks are ideally logged into a Register and should have a profile that includes aspects like Proximity, Likelihood and Impact. Every Risk must also have an Owner who is best positioned to monitor it, this is quite often not the Project Manager.
• Dependencies: List all known and presumed Dependencies. These may be either “on you” or “for you”. Clearly identify those Dependencies which have a chance of impacting the Critical Path. Dependencies are an interesting animal as they can often rely on something which does not yet exist, thus your identification process needs to be quite thorough. A tip here is to consider corporate policies around finance, compliance, data storage/retention and similar subjects. Some companies don’t have these and may have to develop them specifically to support your project especially where you are introducing new technology or systems.

Schedule

By definition a Project must have a start and an end, otherwise it is just Business as Usual (BAU) activity. So, when will the Project Start, what is the expected duration and what is the deadline or expected end date? If you don’t have this information up front, then you are incapable of tracking variance and adjusting plans. For now, they can be ballpark indications, but going through the thought process may surface more CARD Items. Always remember to factor in reasonable contingency.

Project Reporting

Reporting will necessarily evolve across the project lifecycle, for now you should be producing some sort of progress reporting for management, even if it is a verbal catch-up with the Sponsor or Project Executive. As per the first point above, if they don’t want a report then how engaged are they?

Escalation

Another area that will evolve, but early on there must be a clear path and protocol across your team to manage Issue Escalation, Risk Notification, Change Management Items and Project Decisions, i.e. who decided what and when and on what basis. I often bundle Decisions into the CARD Register.

So there you have it, a collection of essential items to work through with the intent of providing you with the best starting point possible for your project. All the best!