Thoughts - Software is critical for PM -

Often we look to software to save us, or to tell us how to do our work.  This is dangerous.  The best definition as to what PM software should do for you is "to better enable processes and improve communication".

Key things improper software roll outs could lead to:
1 - software may not align with culture of how you manage projects and deliver value to your customer
2 - you become dependent on the software to run your business
3 - the software company is not agile and open to change or evolving their application
4 - ongoing licence and user costs are not properly understood and accounted for
5 - software does not integrate with other systems within the company

On the other hand, what software can do for you if properly rolled out includes:
1 - automate processes (saves time, money and resources)
2 - enables more ability to track, monitor, control and improve (data analytics and business intelligence)
3 - improve quality and reliability of what is being communicated
4 - improve collaboration outside your cubicle (geographical constraints are managed)
5 - leads to more mature business management (improves maturity level, strategy, execution, continuous improvement)

As one can see, the lists are considerable for both improper and proper roll outs.  It is critical to plan all software roll outs and ensure proper stakeholder buy in and communication has been accomplished.

Do not fall into the trap of doing nothing or waiting for the perfect software tool and the perfect price. Embrace technology but in a planned organized manner. The "train has already left the station, software is as essential to a company as telephones, pens and paper are."

If not done properly or if not taken advantage of, the consequences are critical to your business and give competitors the edge - especially now that markets are so globally interconnected and some countries are moving much more aggressively in offering better service and value due to their ability to better harness project management softwares.

Some sample links to elaborate on this subject:

Benefits & Risks of PM Software
project-management-software-advantages-disadvantages

Benefits of PM Software
5-advantages-of-project-management-software

Risk of PM Software
Disadvantages-of-Using-Project-Management-Software

Thoughts - Role Alignment with the Person

Is everyone capable to do all types of work?  Can everyone be an Einstein or a Mozart or a Bill Gates?

Often we grow up telling our children they can be anything and do anything.  But then in adulthood, we soon realize we are not successful in everything. Then often if we cannot succeed we blame ourselves or we receive blame from a Manager - this is SOOOO  wrong.

Always remember, avoid looking at the person as not doing a good job.  Look at the person as being an a bad fit within that specific role, within that specific environment.
This fundamental principle is key to understanding and ensuring that both the manager and direct reports are happy and maximizing synergies, personal satisfaction and productivity.

If there is an HR issue, too often the first thing we want to look at fault is the employee.  THIS is not a best practice.  The best approach is to look (in sequence):
  • look at the organizational design structure, 
  • then the management systems in place, 
  • then the strategies (clarity and alignment), 
  • then the Project Manager or Manager (look in the mirror), 
  • then can look at the Employee

When looking at the PM/Employee, fully assess the role complexity and time span of the longest tasks required, then compare it to the PM/Employee in terms of how well these parameters fit with the role:
  • KSE (knowledge, skills, experience)
  • Preference of work (level they want to apply themselves, desire to do the work of that role)
  • Inhibitors (are there glaring things that prevent the person from working in that role)
  • IPC (information processing capability, what level of complexity can they work at, how well do they perform when work becomes ambiguous, abstract, uncertain, multiple events in random series, etc)
  Simple little reminders:
  • often we do not support the concept of hierarchy, yet we all want to be put in a role that we fit with and click with.  We must understand that there are natural hierarchies already established in every working environment. Within mature work environments, the hierarchies are openly communicated and compensation structure and accountability is also much more transparent (we all need to know what our role is and if it is a good fit and then we can all accept accountability to perform what is needed to get done).  This also can enable more self management and self actualization that is aligned between the person and the role.
  • often we see leaders as "good" and mangers as "bad".  However, the manager is so critical in order to get things done.  We often seem to live in a world where there are so many great ideas, concepts, ways to improve, everyone often can have opinions.  But where we tend to fall down is when we need to "get things done according to the planned scope, schedule, budget and quality."

A key take-away:  each job a person does, they must take full accountability whether or not they have the capability to do it.  If it is a "stretch goal" then formal support systems must be in place. 

So both Employees and Managers must confidently know what they like to do (preferences) and where their knowledge, skills, experiences (strengths) lie.  Far too often we do not know ourselves and then we put this job in the hands of managers to tell us the answers and to give us career judgements. Once we can be better at communicating this, there is a "win-win" since it will take much risk, stress and anxiety out of work that needs to be planned and executed.

A good article from the New Management Network to go through and ask yourself these types of questions and to help you better know yourself, or to help a PM or Manager get to better know a team member or direct report, is included at the link below:

Management-Assessment






Tools - Team Development Stages

Teams are usually happy when initially formed, however, soon conflict begins to occur. There is a science behind why this happens.

The PM must talk to the team so they understand, use tools and techniques to help get the team through the low periods.  It is just a phase everyone is going to have to get through and have faith that it will pass and you will get to the next stage.

There are 5 main stages a team flows through from when they first meet to when they are leaving the team.

See video below to help explain:








As described in the video, the stages are further defined below also with a Recommendation/Action that the PM can carry out:
1)    Forming – the team first meets one another, it is superficial, members are wondering if the team is a good fit, what others are like, how they will get along.  First impressions are made (whether they are accurate or not) and most people do not reveal much about themselves. 

During this stage the PM needs to foster team unity and help start laying the foundations to build trusting relationships.  Ensure all members are aware of the project objectives, boundaries and the code of conduct or existing Human Resource processes to be followed.  Also clearly document the roles and responsibilities and provide the required tools, resources, work areas, equipment, etc. as early as possible or address outstanding gaps.

2)    Storming – the team members now start to assert themselves.  Personalities start to come out and may conflict with others.  Control issues start to emerge, misunderstandings of roles and responsibilities are generally an example of one area of stress and conflict.  Stresses of the project may start to appear and test the resources.  Personality strengths and opportunities to improve also start to become more evident.

During this stage the PM needs to identify conflicts as early as possible and address them with the appropriate conflict management technique.  Project issues and concerns must be discussed addressed.  Encourage team members to get involved in solving the problems together.  Include the team, recognize the team and be supportive, positive and enthusiastic.

3)    Norming -  the team starts to work productively and performance levels and output starts to increase.  Conflicts still exist but people are learning how to interact with each other.  Smaller subgroups may also be forming.  Conflicts generally start to be around project or process issues and not around personality differences.  Levels of trust start to appear. 

During this stage the PM must encourage team members to continue to work together and leverage each others skills.  Actively seek out the small groups and promote larger group participation and cooperation.  Confirm ground rules for team interaction and accept people for who they are and respect what they bring to the team.  Healthy debates bring different perspectives, identify examples of trust and build upon them.

4)    Performing – the team is working at a strong level of productivity, the optimum level is achieved or breaking new ground on higher and higher levels.  Conflicts are generally solved by the team members themselves.  Respect, safety and trust is evident between all members and friendships begin to form. 

During this stage, the PM should continue to look for opportunities to promote a more cohesive unit and further enable the momentum.  Also start to look at future needs, e.g. training, coaching, mentoring, provide motivation by conducting more social and open team building events.

5)    Adjourning – the project is wrapping up and winding down.  The team is happy about the new found relationships that have been established but also is sad to leave and may feel anxious about the next project coming up.

During this stage the PM should emphasize the positives in terms of how the team has evolved and the accomplishments that have been achieved.  Formalize a contact list and emphasize the importance of maintaining the network.  Plan a future team event and book it in everyone’s calendar (before everyone disperses).

Thoughts - Value of Managers

All work needs to be managed. If there is no formal Manager for a team, or for a project, then people will naturally take on managerial roles.

So if we understand the logic of having a manager, why do they still get a "bad rap".

The most efficient and effective way to get work done is to have an clear organizational structure that has a formal PM role (the Manager). The PM will be accountable to manage the project and the team and carry out work to accomplish a plan.

1 - key thing that will constantly need management is change. Since a project is unique, many things will occur that were not planned for. Change leads to opportunities and threats, so we need to manage both (enhance one and eliminate the other).

2 - second key thing that needs to be managed is that change will bring conflicts between people.  The primary tool to help manage that is to ensure an environment of trust and respect is installed and fostered as the team goes through the stages of development (forming, storming, norming, performing). Understand that change is not only rationale, it also can be emotional.  This is again why management must be formalized to be able to deal with change.

Value and What to Manage
The PM must ensure to manage these aspects and then the value is achieved.  Look at the project lifecycle and the stages it will pass through, and then the key points that need to be managed at each stage.

An example analogy I recently heard from an expert in Leadership (Shoham Adizes), a project is like making an Apple Pie, you need:
1 - apples (or people) - but have to be careful, one bad apple can spoil the entire pie, so manage the team and ensure all are on side, if not, then changes to the team or the level of interaction will need to be adjusted
2 - recipe (plan) - need to know what are we doing and how we are going to do it, manage the plan
3 - cook the pie (systems) - need to manage the work in accordance to the systems, the type of systems will greatly impact the confidence you will have in the quality and amount of monitoring required
4 - presentation (customized to client) - manage the final hand off of the end product or service, what will you do with the pie, will you package it in cardboard or on a plate with flowers and add extra ice cream, sauce and chocolate, served on paper plate or royal china

Management is becoming more and more complex.  In the old days, tangible things were always the most important.  New companies that achieve rapid success are paying much more attention to "intangible assets" such as the structure, systems, acceptance/embracing of the systems and ability of the people to manage work within that environment.  More research is now becoming available to support the value of management and structure and innovative ways to try and measure "intangible aspects of success".

A leading researcher is Ulf Lindberg (with Requisite Organization International Institute) who has published several amazing articles, for example:
requisite-org-research


Tools - Risk Analysis using PICTA


Before spending time & money on mitigating a risk, did you do proper analysis to provide concrete, tangible, measurable information that will support your decisions?


Risk analysis focuses on attaining the details related to the risk events.  One method is to focus on the process of determining probability and impact of the risk.  This information forms the basis of how risks are analyzed, prioritized, ranked and ultimately responded to. 


The two main parameters to always know are PI (probability and impact).  However, additional ones also include: Cause, Timing, Frequency and Alternatives.

See video below for an explanation on what the tool/acronym PICTA stands for:


Try to remember the word PICTA - Probability, Impact, Cause, Timing/frequency, Alternatives.  
Keep that in your back pocket at all times to help focus on key parameters of risk analysis.


Supporting details related to the two key parameters are included below: 

Qualitative risk analysis should follow a systematic approach to identify:
  • Probability – the likelihood that the risk event will occur.  The probability should be assigned a numeric value.  The definition or scale must be detailed enough that there is no misunderstanding by stakeholders.  The scale may range from 0 (will not occur) to 0.5 (in the middle, may or may not occur and has an equal change for each) to 1 (certainty that it will occur).  It may also help to draw a scale (people can then visualize it).  
  • Impact – this reflects the magnitude of the consequence how the project will be affected if the risk event occurs.  This must be assessed by the team with a focus on the project as a whole (generally the objectives should be reviewed and compared to the types of consequences that could occur).  More detailed impact analysis could be done later in the risk planning stages with a focus on a more specific area (e.g. scope, time, cost, quality, training, etc) but this should follow a more customized risk management approach with specific resources assigned.  Similar to the probability scale, the  impact scale definition must be detailed enough that there is no misunderstanding by stakeholders.  Generally the scale will have a column that assigns the impact a numeric value and also a column with a definition. 
An example includes:

Impact Value
Impact Level
Definition
1
Low
Impact will be minor and not noticeable outside the project team
3
Medium
Impact will influence the plans of the project, corrective actions will be taken, active response planning will be required
5
High
Impact is major and stakeholders outside the project team will need to be immediately involved

Once the probability and the impact guidelines have been created in a standardized and consistent format, a matrix can be built to prioritize risks based on the combination of the two factors.  

For additional details on a risk matrix approach using PI, see a journal paper at the link below:
scientificpapers-risk-analysis

Thoughts - Being on Time -

Projects in other countries often follow a different approach to time management then Canada/USA.

The world is now highly connected so chances are good that you are working with people from other cultures (direct on your team) or are working with people that are in other geographical locations (other cities or countries).

Often in Canada/USA, when we put a time stamp on something (a meeting, a deliverable a start or end point) then we want to be exactly on that time stamp (not before, not after, but right on time).  PMI and other methodologies also teach that being on time is so critical since there are so many other interdependencies that could be impacted if the timing is off. Thus it can be said that Canada follows a much more rigid approach to time then many other cultures.  

Is this good or bad?   Had some great discussions about this topic on a webcast with another Project Manager from Brazil. 

Some neat ways to look at things included:

When we in NA stop at a stop sign, we come to complete stop.  They will slow down and only stop if it is necessary.  So in a PM perspective, it can be seen as:  
- in NA we follow the exact rule, like a waterfall approach, will have the plan and must execute the plan
- in Brazil, they can follow a more agile, fluid or dynamic approach, and have the guideline but the user has more power to decide exactly how much detail should be carried out in the plan

Food for thought, which way do you think is more advanced?    Which way do you think empowers the resources more?  Which way do you think people will also have more pride and ownership over the decisions they make?  Which approach  allows for more innovation and trust with the people doing the work.

Check out the webcast at where a Guest Speaker talked about this topic and lives it as he works on projects between South America Culture and Canadian Culture:


HOWEVER, on the other hand, it can be seen as disrespectful and cause conflicts if some people arrive on time or execute on time and others do not.  Also the level of interdependence of tasks within projects needs to be managed, thus being late for one thing may lead to being late in a lot of other things and lead to major risks in scope, schedule, cost, quality, etc.

The key thing the PM must do is to understand the culture operating within the project and how timeliness for meetings, deliverables, etc is to occur.  This needs to be reviewed, documented and formally discussed at the earliest stages of the project. Set foundations of how things should be for the life of the project.
 

More food for thought can include.........

Another way to look at time is what it means to that person in that specific moment and in relation to the longevity/randomness of the event:
  • 1/10 of a second to someone who missed an Olympic gold medal in sprinting
  • 10 seconds to someone who missed a gold medal in long distance marathon
  • 1 hour to someone who missed a high mortality multi-vehicle pile up
  • 1 day to someone who missed a massive earthquake or tidal wave

Another way to look at time in a more humourous way came from a recent blog by Jeff Mowatt:

Business Etiquette - Are you On Time?
Question: What time should you arrive for a 10 o'clock business meeting?
  • 9:50 - you're bright and early
  • 9:55 - you're early; but not so early you look like you're wasting time
  • 9:59 - you're there in the nick of time
  • 10:00 - you're exactly on-time
  • 10:05 - meetings don't get going for the first 5 minutes anyway

I learned the answer years ago as a first year business student at the University of Calgary. A HR manager from Trimac Trucking came in to speak to us about the real world of business, making a positive impression, and getting hired. He explained that if you show up for a meeting late, you're disrespectful to others. Showing up 10 minutes early indicates you haven't got enough to do. Arriving exactly on time or 1 minute early makes you look rushed and disorganized. Hence, the correct answer to convey courtesy and competence is b) 9:55.