« Project Signoff Points
Project Team Organization »

How to Start a Project

February 19, 2009 | Author: PM Hut | Filed under: Project Management for Beginners

How to Start a Project (#3 in the series Project Initiation - It Is Only A Start)
By Azra Duric

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:

  1. You have no time - You are up to your neck with your project
  2. “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.

Projects are a strong connection between business and technical sides in an organization

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:

  1. What will happen if this project is not done (in both quantitative and qualitative terms),
  2. Why is it better if it is done and by how much,
  3. In the scenario this project is a no go what would your workarounds be
  4. 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.

Azra Duric is a certified Project Management Professional (PMP) with 15 + years of experience in the IT industry; spanning the government, financial, education and other non-profit sectors. She has a degree in Mathematics from the University of Sarajevo, Bosnia and Herzegovina and a Post Graduate Diploma in Office Systems and Data Communications from the University of Leicester, England. Since Azra moved to Canada in 1996 she has been working in a variety of government and non-profit sectors in Ontario and has been professionally working as a project manager for the last five years. She is a member of the PMI-CTT (Project Management Institute Canada Technology Triangle) Chapter and WIPMSIG (Women in Project Management Specific Interest Group). Azra lives in Guelph, Ontario and can be contacted at durica@sympatico.ca. More information about Azra can be found on her blog http://azra-pmp.blogspot.com.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Thursday, February 19th, 2009 and is filed under Project Management for Beginners. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories