Project management is not an easy undertaking.  It involves managing and juggling many variables and constraints.  Many people and factors interact and affect the output, time and cost of the project.  It is important that there is a certain discipline in running the projects.  Also, project management is as much of an art as it is a science.  Based on our experience and understanding, we are sharing ten critical elements of project management that help make lead to success.

10 Critical Elements For Successful Project Management Click To Tweet

The 10 Critical Elements of Project Management

What are the 10 critical ingredients which lend themselves to successful projects?  Here are the list and its details.

1 Get the Big Picture: No matter how small or how big the project is, it is important to know why are we doing it?  Unless we recognize the overall reason and impact of what we are doing, the chances are we will less commit to it.  Construal level theory (CLT) in psychology suggests that if there is a distance from an object – even temporal or in terms of understanding – the more abstract it will seem and looked at.  Abstraction with respect to the goal is the last thing one needs when managing a project’s final delivery.  One needs to have clarity and solid project plan to get to the final step.  The work on Cathedral Notre Dame de Paris was started in 1163 when its cornerstone was laid.  The entire work was finally completed in 1345.  That’s a 182-year project!  And this project involved so many things – architecture, material, labor, changing kingdoms etc.  Working lifetime for most people wouldn’t have been more than 30 years, 50 at max!  Yet the vision and the plan was handed down so well to finally accomplish the task.  This could happen only because everyone working on it understood the significance of the work they did to their culture, coming generations, and religious needs.  In absence of this understanding of why the project I am delivering is important and significant to my company and the world at large, the commitment would be lacking.  Lack of commitment translates into lack of rigor and detail.  And, that is disastrous for the successful delivery of any project.  So, first of all, understand the WHY of the project.

2 Understand the Project Charter: In the entire list of the project documentation and process steps, the Project Charter is the main one.  It sets the tone for everything.  The Charter contains the statement of the scope, objectives, and participants in a project.  It is a document that provides the clear roles and responsibilities and lists the main stakeholders as well as defines the power and authority of the project manager.  The main Terms of Reference (ToR) for the project are enshrined in the Project Charter.  Here are the different sections of a project charter.

  • Project Authorization – Name of the project along with a brief description of the project.
  • Scope and Vision for the project – The high-level goals, vision and the scope are defined.  The preliminary scope describes what the project involves, the high-level resource requirements, and project completion criteria. If the team knows any risks (high level as of now) can also be included.
  • Deliverables – this is where deliverables at a high level as required by the client/business, project sponsor or stakeholders are defined.
  • Benefits from the project – the benefits of the project to the organization and how the project contributes to the organizational objectives are discussed in the charter.
  • Project Manager’s Authority – Project Manager’s name is stated and also s/he gets authority from this document.  The powers of the PM are defined here.  The cadence and ways in which the PM can interact with management and allocate resources to the project. Based on whether it is a matrix or functional or projectized organization, the project manager will have varying levels of authority and responsibility for resources, scheduling, and expenditure.
  • Timeframe – The broad schedule and major milestones of interest to the sponsors are set out in this section. This will change and get more detailed during the initiation and the analysis phase.
  • Budget  Summarysets out the preliminary summary budget for the project.  This may also change as the project progresses, but any changes must be communicated by the project manager and approvals gained. The Project Manager is authorized to approve expenditures up to, and including the allocated budget amounts.
  • Project Sponsor – sets out the name(s) of the project sponsor(s) and the sponsor’s signature.  The project sponsor is the appropriate person to sign the charter because he or she is the person who will be actively supporting the project. You can also think about getting your customer to sign the charter as this displays confidence from both the sponsor and the customer.

Project Charter is written by the Project Sponsors.  It is imperative that the project manager knows the details of this document well and has the discussion about the contents before starting the project.  Any questions/doubts should be clarified. This is an important element of project management.

3 Know your Stakeholders: Stakeholders are those who have an interest in the project.  These people and/or entities can be internal or external to the organization where the project is being done.  Their impact can be either negative or positive for the overall success of the project.  It is therefore important to keep them engaged and know what their needs are.  Stakeholders are people who are your sponsors – those who fund the project and thus are impacted financially if you don’t do the job well.  They are also those who either impact you – Upstream to your process or are impacted by you – downstream to your process.  Both the Upstream and Downstream processes need to be aligned with your changing world.  As an organization, your project cannot break the whole process chain.  Projects bring in change and change brings in risk.  Change Management has a direct bearing on the risk associated with the project.  The Managing Change in Organizations: A Practice Guide by Project Management Institute (PMI) says:

“Trust is identified as particularly important in obtaining support for and participation in change efforts. Executives and employees see change differently: (a) senior managers typically see change as an opportunity for both the business and themselves; and (B) employees typically see change as disruptive, intrusive, and likely to involve loss. When managing change, it’s essential to identify the key issues, such as loss of turf, attachment, meaning, future, competency-based, and/or control.”

The change in turf, attachment, meaning, control and competency are all with respect to all those who are impacted by the project – i.e.; its stakeholders.  Change that takes away the central reason for their existence in an organization can be a good reason for them to either not go along with the project or, be against its underlying objectives.  Both aren’t good options.  So know what makes your stakeholders tick.  Understand why they are into this project.  That will help you tailor and custom your communication and engagement with them, taking care of their specific needs. So keep in mind that, understand your stakeholders is another key element of project management.

4 Create a structured Project Documentation Repository:  During the project a lot of documents are created.  Many versions are there.   Keeping them and managing the documents which can serve as audit trail is imperative.  What is written in the original charter and then the business and technical requirement documents needs to be aligned with what is delivered in the end.  From Analysis to design to build to the final testing, it is critical that one has a tie-out of what was required by the client and what was finally delivered.  There are three aspects to it –  (i)Where are the documents stored (application), (ii) How are they stored (structure), (iii) How proper documentation and its storage is managed (cadence)

Most of the companies use Microsoft’s Sharepoint as the main documentation and interaction repository.  There are, however, other alternatives like Alfresco, Huddle, and Samepage.  All these applications provide not just document management but also collaboration and interaction.  They have tons of integration with other applications.  Alfresco also has an Open Source version.

The project repository should always be owned by the project manager who is responsible for the quality and content and has to ensure that the rules of use are followed by all team members.  At the beginning of the project, the PM should share the structure for the folders and the main rules/policies with respect to the document repository with the team members.  Setting standards to be maintained is the job of the PM.  One useful tip from a friend that we think is of great use is to always include an instructional text file for each directory and sub-directory, which lays down the rules and conventions for the documents in that folder.  It is like the readme.txt file that is there are most programs that developers write.

5 Know and Engage the Client / Business Users: On so many projects, I have found that ultimately listening to the business users and/or client was critical for the success of the project.  On one project, we had representation from each business group on the main project team.  Despite the fact that we knew the representative from one of the critical groups did not get along well with the Director there, we took his version as the truth.  Later, in the User Acceptance Testing, we found that what we had delivered was of no use to the business.  Ultimately, I had to sit down with the business users for hours just listening and trying to deliver the solution to them.  When people do not listen to the users of the project deliverables, they usually get into situations where the final outcome is set for rejection.  So learn to listen and engage with them and get their inputs at every point of the project.  In fact, make it a collaborative process.  The environment should not be one of distrust or silo functioning.  It is fine to mingle the IT and business teams so they know each other better.

6 Factor in the individual schedules: A project has many moving parts with many teams involved.  These days mostly the project teams are global in nature with team members working across geographies.  Each country and community with many countries have holidays and important days at different times.  Have you factored those in?  I have managed projects with teams from China and India.  While India follows the normal “slow time” of Christmas to New Year and has many other holidays including national days off, China doesn’t slow down during the Christmas to New Year timeframe.  Instead, most of China is off during the Chinese new year or the Spring Festival for them.  Chinese origin communities everywhere – including Malaysia, Australia etc take that time off.  So we have had to build our schedule factoring those days off.  Apart from that, every individual will be taking their vacation days.  Know them and add them to your schedule.  This may seem like a small thing, but believe me when you are heavily into the System Integration Testing (SIT), things can go completely off the rails if you have not taken into account the holidays and vacations.  So document everything.

7 Be Culturally Aware and Sensitive: Not all cultures are the same and more often than not, your team members will come from very different cultures.  All the cultures bring their own characteristics of decision-making and interaction.  It is important, therefore, for the project manager to be observant and understanding of these differences.  There are many models for cultural behavioral ways.  The one by Richard D. Lewis is the most popular.  It differentiates the global cultures into three categories:

  • Task-oriented, highly organized planners (Linear Active)
  • People-oriented, loquacious inter-relators (Multi-Active)
  • Introverted, respect-oriented listeners (Reactive)

Basically, Lewis looked the existing models and suggested that they were too dimensions considered by them leading to confusion.  The model was shared in the book – When Cultures Collide (1996).  Lewis came up with this categorization after having to visit 135 countries and working in 20 of them.

Lewis Model of Cultural Classification
Lewis Model of Cultural Classification (Courtesy – Cross Culture)

People from these different cultures are NOT homogeneous.   They are all different.  Yet, some traits always remain strong from the cultural influences of childhood.  Also, in any culture, not one trait is exclusively present.  The model suggests those traits which are predominant.

One thing from personal experience I have found is – that there is no substitute for honest engagement.  Be honest and work with people with integrity.  Give them genuine respect.  Do not “fake” anything.  Human to human interaction when genuine is always effective.  There have been times in Venezuela and in Shanghai when I was having a very engaging conversation with cab drivers who did not understand a word of English and I didn’t know Spanish (very little Spanish) or Mandarin.  Yet, I and those can drivers knew what the other was saying.  The same thing worked in projects.

8 Get the Project Schedule Ready Early:  NY Yankees baseball star Yogi Berra once said “If you don’t know where you are going, you’ll end up someplace else.”  As hilariously profound as it is, it describes the very reason why every project manager needs to get the project schedule done as early as s/he can.  Granted that not all the details are in place always for the PM, and things are fuzzy or unclear, but a PM needs to know how to find ways to express the understanding of schedule and time as tangible as one can.  There is always a need to do estimation, and most of the project managers have to rely on their experience and that of their team members to come out with a quick schedule at a higher level and then start detailing it.  The schedule is never set in stone from the get-go.  One needs to come up with a schedule and then bring people onboard and have negotiations.  This will enable a PM to get clarity on the timeline.

Basically, a schedule lists down all the tasks to be completed during the project and also it includes who will do what.  Resources and teams involved in the entire work are imperative to complete that task.  The project schedule can be of any type – (1) a milestone chart and list, (2) a high-level Gantt chart and (3) a detailed project schedule with resources included (usually in MS Project).  Generally, a PM goes from the milestone chart to the detailed project schedule with resources.  You can get some basic project timeline templates in Excel and Powerpoint here.

9 Know your team well:  Every project manager knows extremely well that in the end it is the team that delivers the project collectively.  There are few outstanding contributors but everyone needs to pitch in.  And people go through several life situations during the course of a project.  Someone may be moving to a new country and while you are looking at them to complete a deliverable, s/he may also be grappling with visa issues or trying to find a place to stay.  It is important that the project manager works with everyone to ease out the situations that people are in.  I have seen that many people on projects in India and China may be working in Bangalore or Shanghai but they belong to a different city/town/village.  And, during the long weekends, they prefer to take a day off and travel to their “native place” to be with their family.  A good project manager needs to work with these team members so they can get quality time with their family and come back recharged.  Remember, not all towns and cities have proper internet connections and they cannot be expected to work during their time off, even if they were ok with it.

A good project manager knows his/her team very closely.  It is often a great idea to bring the team members together along with their families so it is a much bigger connection that just sharing deliverables on a project!  Know what makes people tick.  That will also help you to customize your communication to people.  It would be foolish for a US-based PM to use baseball analogies with a team in India.  S/he will be much better-using Cricket terms and analogies.  I have had project managers in the US, who have given the entire day off for Diwali to the team (predominantly Indian developers) even when it was a working day.  These things matter a lot in building trust and respect for the leader.

10 Understand the risks to the project:  Every project has several risks and areas and a project manager needs to be clear about what they are.  They can stem from: Executive level risks, Scope definition, Cost-related issues, change management under-estimation, stakeholder issues, Bad Communication handling, and resource capability and availability issues.  The APM Body of Knowledge describes risk as: “an uncertain event or set of circumstances that, should it occur, will have an effect on the achievement of one or more objectives“.  So often the PMs underestimate the devastating impact that risks may have on the overall timeline and schedule.  It doesn’t matter how small the risk may be, it should be documented along with its mitigation and ETA.  Sometimes even small risks can become really big.  It is good to look at the matrix of Likelihood vs Impact of the risk.  Where a risk falls decides what type of action is needed.  Here is a Risk Management Model

Risk management model
Risk management model

Steps to mitigate and manage risks

1. Identify and monitor risks:  The first step to managing any risk is to be aware of them.  This needs inputs from all the team members – business and IT.  It is important to understand what is going to cause uncertainty to the project.  It could be something like different holiday schedules in different geographies at critical times.  If your business SMEs are said in China, and the UAT is planned around the time of Chinese New Year in late Jan/early Feb, the chances are your UAT will be badly impacted.  That is a risk that one needs to factor in.

To manage and monitor risks, use a risk register.  Usually, one should use an online tool like the Sharepoint to create this list and provide access to the team members so they can add to it with their responses and updates.  Here is an example of a Risk Register

2. Assess and Analyze the risks Quantitatively and Qualitatively:  There are many ways to quantitatively analyze the risks.  Use of any method depends on how large a project is and what information you have.  The method you use is also a factor of time you have at hand.  One shouldn’t analyze so much, that the time runs short to actually execute the project deliverables!

Quantitative Risk analysis uses an objective approach.  It takes data and statistics to evaluate and quantify the risks and their impact on the project – both timeline and success.  The main Quantitative methods are:

Heuristic Methods:  These use experience or expert based techniques to estimate the risk contingency.  These include:

  • Percentage of Total Values
  • Predetermined Guidelines
  • Controlled Interval and Memory
  • Case-based Reasoning Model

Expected Value Methods (EVM): is calculated as a product of the probability and time/cost exposure of the risk.  These include:

  • Method of Moments
  • Expected value of individual risks

Probability Distribution Methods: These methods calculate risk statistically using distributions.  These include:

  • Monte Carlo Simulation
  • Range Estimating

Interdependency Models: these use the dependencies between the activities using the logical and resource constraints.  They include:

  • Influence Diagrams
  • Theory of Constraints
  • Analytical Hierarchy Process

Empirical Methods:  These methods use historical information that is present within the team.  Past projects, if they are enough in number, present the team with statistics and data that can be mapped and correlated to the current projects at hand.  These methods include:

  • Regression
  • Factor Rating

Mathematical Modeling:  Risks can also be calculated using detailed mathematical models using linear and non-linear variables.  These methods are far more involved than any other.  Normally, very few projects use these.

  • Artificial Neural Networks
  • Fuzzy Sets

Qualitative Risk analysis is a more subjective way of assessing the risks.  It involves taking the Organization process assets – procedures, policies, and historical information – as well as an evaluation of the Enterprise Environmental factors and looking at the project risks.  This method takes Risk management plan and the risk register as the inputs and assesses the risks and their impacts.

Go for it

Using the tips above which are very critical elements of project management for any manager, you should go ahead and run your projects with complete confidence.  And please check back as we will add to this post with some other information as well.

About Desh

Desh is an experienced Program/Project Manager. Strong at turning around projects, managing tough business users and working with cross-cultural development and business teams. Aggressive leader who thrives at tight timelines and near-impossible situations.

View All Posts

Get more stuff like this

Subscribe to our mailing list and get interesting stuff and updates to your email inbox.

Facebook Comments

You may also like

Change Management: Kotter’s 8 Step Change Model

Change Management is tough.  But it becomes tougher when we have to institutionalize change that drives the corporate vision.  John Kotter create the 8 Step Change Model, which has become the industry standard on heralding change and making it stick.  A detailed article on the whole process by Kotter.