Project Initiation - It is only a start, or is it?

So you’ve just heard through the grapevine that a project you always wanted is going to be yours! You are going to be “the” Project Manager of this big, beautiful and popular beast everybody was buzzing about. How nice and exciting for you! Once the initial excitement is gone you switch to reality and all those uneasy thoughts about starting the project on the right foot. Right?

Project Initiation

We learned by now that the Initiation is the most important phase of any project. We are even told that with a good start and good high level planning one can consider half of the project complete. No pressure here, but it is more important to do a right project, than to do it right! So why is there so little literature available about this phase? Maybe it is due to the realization that you need to apply more common sense and less methodology, and there is no tool that can guarantee you a good start if you don’t have enough expertise, or if you are not guided by other experts on your way.

Since we are talking about common sense, it is up to the individual project manager to find the best way to deal with this most important, but also most grey area of his project. By the same token, the tips that I am suggesting here are just a collection of lessons learned I acquired throughout my informal and formal career as a project management practitioner. If I succeed in helping you avoid even one pitfall in your next project then this article will be worthwhile.

You will find many of these tips familiar and something that you are already doing and there are for sure some other tips not mentioned here. If so, I am inviting you to write to me about it and if I collect enough of additional material I promise to write about it again. Please email me at durica@sympatico.ca.

Before the project - Who I am and where am I?

First, you need to understand the culture, the vision, the mission and the project management structure of your organization. Apart from a myriad of technical and soft skills you have to posses, it equally important to understand the business side of your organization and your department.

Before you start with any project you need to understand the role you have in your organization. In addition, you need to know the position you are on your project management career ladder. The lower you are on this ladder (not that much experience or you have been recently hired), the more time you have to spend preparing for the project. This is ironic because the less experience you have, the more susceptible you are to the influence of others, which can sometimes be negative and hold you back even more. If you are lucky and have good mentors with enough power you will find yourself in the fast lane to potential success. On the other hand, if you are influenced by others in a counterproductive way, or have nobody to help, you will have to work much harder, but will gain bigger rewards in the end.

Before the project - What are my tools and techniques?

After you have the right orientation of your position in the organization, you need to look for your tools that will help you in your project management work. This is a very important phase and you should never rush through it, even if you are told otherwise. Just as you may not know the tools that a mechanic uses to fix your transmission, those around you may not realize what tools you need to develop your solution into a project.

The sophistication of your tools, or methodology and processes will greatly depend on the organizational structure and its maturity. The advantage of project- oriented, PMO-enabled and mature organizations is that they usually have a myriad of project management related tools and processes. A disadvantage is that they may be strict and impose them on you even if you feel that an alternative would better suit the situation.

If you are in a small, functional or a weak matrix organization, there most likely is no formal project management methodology. If you are in an average organization these days you probably have at least a Charter, Plan and Status Report templates. If you don’t, create them! Use this advantage and your creative senses to be a pioneer in helping establish a proper methodology for your organization.

The Project Charter should be your bible and your best ally. It should state clearly who is responsible for what on the project. This statement will frequently become very handy for some people who have short memories, unintentionally or otherwise.

The Project Plan should be your best friend and an all–in-one daily report, which you always have to keep in harmony with the Charter. Start the Plan like an empty book. Begin with the Preface (taken from the Charter), followed by the Table of Contents (written during the planning phase) and then Chapters will be written during the execution phase.

Your weekly Status Reports/Meetings are too important to miss, even if you are told otherwise. Those reports/meetings have a dual purpose as a great monitoring and control tool. They keep you in check, as you HAVE to know where your project is at all times and communicate it to others. While you are preparing for a status report you are also on top of your risks, issues, and of course status (time, scope, resources, and quality) of the project. If you are not required to have weekly meetings you should push the status reports in weekly e-mails to your management, sponsor and the client, at the very least.

It is very important to adopt project management standards, methodologies and procedures that work well in your circumstances. I understand the urge we all have to make shortcuts and try avoiding some stuff we find boring, such as documenting emails you get from your clients, or indicating in the Plan the exact outcome of your project and accurate measures of its success. What I discovered, however, is that my best and easiest project was the one where I applied project management methodologies taken from the industry best practices and tailored to my organization. I then followed, religiously in fact, the self-imposed process even in cases I was not asked to.

Finally, once you establish the methodology and processes, resist using Microsoft Project or any other project management application yet at this early stage. As I mentioned already, once you pass the stage of making sure that your project is right you want to make sure the project is done right. Make sure you establish a stable baseline first before entering your artefacts into the system to avoid the inevitable re-work imposed by changes.

Starting the project

It is rare, unfortunately, to have project managers involved from the very beginning of the initiation phase of projects. The early involvement from the business point of view would be of an enormous advantage to any project manager, as they would have better understanding and appreciation of the problems and opportunities they are supposed to solve.

If you are not that fortunate and are just being told to start your project today and finish it tomorrow, don’t worry. Try to put yourself in a position of people and departments affected by the problem and you will have a much better chance to lead your project and your team into a successful solution. By believing strongly in the project objectives and knowing the extent of the achieved benefits you will not even notice the burden of the responsibility you are taking. This strong belief will be an invisible shield that should comfort you on your way to success.

It is always good to know a little more behind the boundaries of your own project. The initiation is the perfect time and probably the only time to gather this knowledge. Once you are in, let’s say business requirements stage and you would like to know more about another project that can dangerously impact yours, I bet you the following will happen:

a) You have no time - You are up to your neck with your project
b) “It is not your business”, you are told and “Don’t you have enough in your own project?”

It is important to understand the position that any project has in an organization. Since the business and technical sides are usually acting in isolation, every project’s role is to merge these two sides effectively, by acting as a transition of its business objectives into its technical implementation. See Figure 1.


Figure 1 – Project is a strong connection between business and technical sides in an organization.

Hence, your project’s objective, and the reason you have this job after all, is the connection between a business need and technical delivery to accommodate that need.

If you have at least one of your project constraints flexible to some degree you will manage the project. If you have all these constraints fixed you will need to manage your stakeholder’s expectations to get some needed flexibility in your project. In order to manage them you need to understand them. The most important mission you have as a project manager is to put those stakeholder’s expectations into quantifiable statements and manage them within the boundaries of your own project. It is like your project is in a cloud floating above your organization, see Figure 1, and your goal is to clear up this cloud and land the project safely to the best place it can be between business and technical sides. You do not want to be lost in that cloud yourself, hence the reason to start questioning.

Ask questions, and then ask some more

As I indicated earlier, the most important fact to determine at the start is if your project is the right one. So you need to ask questions to find out. The other truth, which may be good or bad news depending on your inclination to be less or more technical, is that you will always have to ask questions throughout the project. What is happening, though, is that the more your project is advancing, the more and more questions others will ask you. Your exclusive opportunity to question others has a short timeline, so you need to use it to your advantage.

The initiation and planning phase of a project has a strong resemblance to the work that your Business Analysts are doing. They start with the requirements elicitation, including negotiation, validation and management of collected requirements, followed by test cases and so on. Similarly, you are determining the scope of your project, starting with interviews and meetings with your stakeholders; you gather and validate the scope and other constraints; you acquire the additional knowledge by research activities and finally you and your team document and manage all project-related artefacts. It is just that your scope is multi-faceted, with more dispersed activities across more functions, you are dealing with more stakeholders and finally you have more responsibilities. Even the responsibility for the requirements your Business Analyst is doing is also yours.

Ask as much as you can, but have your questions well prepared in advance and be careful about taking other people’s valuable time. In your wording you want to get your point across as a confident expert. So you will not say to your sponsor: “Are you sure that this project you initiated two years ago, spent so much time pushing through, started only briefly last summer and failed, is really right thing to do?” You may think that, but you need to say just the opposite; how you are honoured by this task, how you appreciate what management has done with this project so far and how you are the right person who will help them with this project, no matter how challenging it is.

You may have a Charter ready for you, you may even be involved in its creation and/or validation, or there may be no Charter at all. In any case, you need to have a written document, which is a contract between you and your management. By accepting the Charter you are taking responsibility to deliver, whatever is stated there. So you need to understand clearly what has to be done, why, who is doing what, who is responsible for what, when, how much it will cost and most importantly how anybody will know if the final outcome is success.

I can’t stress this enough, this is your best chance to probe, ask questions, negotiate your project’s position, address the existing organizational risks and not only understand, but also embrace completely its objective. All this, so you will be prepared to defend fiercely the path on which you and your project are going.

What to do and Why?
To be able to feel good about the project and feel confident throughout you need to ask your sponsor and client what has to be done and why. There are many other sub-questions on this topic you may ask, such us:

a) What will happen if this project is not done (in both quantitative and qualitative terms),
b) Why is it better if it is done and by how much,
c) In the scenario this project is a no go what would your workarounds be
d) Etc.

The more you know, the easier it will be when the tables turn when those same people, in addition to everybody else, ask you what you are doing and why. You better have an enthusiastic and uplifting response! The response will not be the same all the time as it is impossible to finish an average project without any changes. So when assessing any change request that will come your way you need to ask yourself what you are doing and why, before determining how the proposed change will affect your course.

In addition to knowing the objective of your project, you need to determine the success factors, i.e. what are the metrics that you should apply in order to know if the outcome is success. One of questions to your sponsor and client would be what their expectation of this project is and how exactly they would know if its outcome does not meet their expectation. If you can quantify what and why, you already have the answer to this third piece of the puzzle. For example, if the goal is to decrease customer calls for 20%, you need to know by when and determine other logistics about the benchmarks and you will have the answers.

How much will it cost?
This is an obvious question and I do not need to spend much time on it; pun intended. The most important discovery here is to determine the risk adverse factors from your sponsor in regards to financing. Is there any flexibility to increase the budget figure if necessary, how much, when etc. You need to know how much room you have for your project’s dance.

Who?

This is the trickiest and most risky area. If you do not ask proper questions here you may end up regretting it down the road. Starting with the Project Charter you do not want ambiguous statements and confusing roles. At a minimum you have to insist on clear statements for roles of yourself, your sponsor, your client and any other manager, or coordinator for any roles they will have on your project.

You should insist on having only one client. If not possible then you need to split the objectives to the appropriate clients as the Champions. Do not accept two clients for one requirement! It is same as you would give a project to two project managers, with absolutely same roles in it. Who will then be responsible when something goes wrong? And for sure it will, because it is not clear who will do what and who will not do what. Especially avoid having two clients with the opposing views, or even worse a sponsor and a client in conflict!

In one of my projects with the objective to enhance an application, one client insisted on adding an interface component, while the other fiercely resisted having that same component! What was interesting, both clients were telling me: “You should not forget that I am your client so you should do as I tell you!” After initial frustrations I finally negotiated one primary client, who was responsible for scope determination and approvals, while she negotiated separately with the other client. Your sponsor can also help to make sure these boundaries are set. To be safe you always need to know who has the last word and clearly state it, starting from the Charter.

At the very start of your project you need to have a sense of resources availability. Companies usually do not have the capacity planning in that regard, so you need to determine as soon as possible what your playing field is. Knowing you do not have appropriate or enough internal resources you could start asking your sponsor about it. It is very common for the sponsor or your manager to grossly underestimate resources and you can’t blame them, but since it is your project you need to make sure to cover all the bases for the project.

With what?
System resources are especially tricky, since they are not visible like people and can be easily forgotten. There may be some essential systems or parts of the systems that are most likely going to be unavailable when you need them for your project. If this is out of scope of your project you need to clearly identify them as the organizational risks as opposed to your project’s risks. Why would you take responsibility for something that is not yours and you do not have a control of? Don’t you have enough risks and responsibilities already?

For example, if your test phase depends on acquiring a test server, and the acquisition is not in your scope, do not write in the Assumptions section of your Project Charter, or worse Project Plan, something like: “It is assumed that Test server will be up and running a week before Test Phase starts”. If this is the only action you take nothing will happen. Even if you escalate this issue 2-3 weeks beforehand to your sponsor saying that the Test server is not ready, it will be of no help. You will have to defend your inaction, forgetting it was not even your responsibility in the first place. Start immediately with a list of the existing organizational risks, if such a list does not exist already.

Clearly indicate what resources have to be purchased/installed/configured/refreshed, by when it should happen, and most importantly, who will be responsible for this to happen. You will still monitor this activity, as it is impacting your project, but rest assured that whoever is responsible for this to happen will make it happen. If not, any change in your project status resulting from this activity will not be your responsibility.

Where and When
If you are aware what your role and your organization/department role is this part will be obvious to you. You will know by this time where you and your project are in the bigger picture, what other activities, as well as capital and/or operational projects are taking place at the same time as your project and the time constraints of your and other projects. You will also know what your role is in acquiring the best team you can get, as well as other resource dependencies that you have to watch for.

I already mentioned that you have to be aware of organizational and your project risks so you will add some of these in both lists of risks/issues. It would be good to point out to your sponsor and client that ultimately the organizational and/or departmental well being is your top prerogative and any serious changes in their course that impact your project will be taken into account accordingly, even at the expense of you project, if it needs to be.

At this point you should be busy and dig out any historical information, lessons learned and best practices from documentation available in your organization. If that is not available you should go through requirements elicitation process to gather this information by asking appropriate people.

And finally… how?
After you have answers to every other question, this one will address how you go about doing your project. This one is the easiest because you are very much in control of the way you do your job. Once you know what the objective is, who the players are and what tools you have, it is much easier to determine how you can achieve the objective, how to approach stakeholders and how you use your existing or acquire new project management tools.

Conclusion
There are many other questions that you could and will ask than the ones I mentioned. In order to address this topic in more detail, one would need to write a book and I am sure those books already exist. The intent of this article is to help you be aware of your environment so that you are well prepared and gain much needed confidence for the success of your project. Only if you know what you are doing, why, with whom you are dealing with and where, you will be well prepared for surprises on your way. With this awareness you do not need any luck on your project, but I wish you the best of luck anyway!