Good Manager and Good Leader in Project Management

In our text, Chapter 10 Leadership: Being and Effective Project Manager states the following section in Managing versus Leading a Project:

In a perfect world, the project manager would simply implement the project plan and the project would be completed. The project manager would work with others to formulate a schedule, organize a project team, keep track of progress, and announce what needs to be done next, and then everyone would charge along. Of course no one lives in a perfect world, and rarely does everything go according to plan. Project participants get testy; they fail to complement each other; other departments are unable to fulfill their commitments; technical glitches arise; work takes longer than expected. The project manager’s job is to get the project back on track. A manager expedites certain activities; figures out ways to solve technical problems; serves as peacemaker when tensions rise; and makes appropriate tradeoffs among time, cost, and scope of the project. However, project managers do more than put out fires and keep the project on track. They also innovate and adapt to ever-changing circumstances. They often have to deviate from what was planned and introduce significant changes in the project scope and schedule to respond to unforeseen threats or opportunities.

 

I have lead and participated in my fair share of failed projects, because as stated in the text we do not live in a perfect world. I think the biggest reason my failed projects failed was due to lack of engagement and commitment in the team. When the business needs to get something done, it gets done. We have our fair share of people who can rally the team when needed, but all the small “like to haves” or “better than” projects seem to fail because people are not interested in continuous improvement when they have to struggle to keep their heads above water when trying to complete their own work let alone a project. That is why this section resonated with me, “the project manager has to innovate and adapt to ever-changing circumstances”. This type of flexibility is critical in any and all projects. I know that in my world in healthcare we have more failures than we have success, but we keep persisting because those successes are worth all the effort to get. One common thread in my successful projects that I found to be most enjoyable to participate in, was that I had a good manager and a good leader. The text describes the difference in a leader and manager in the project as, “Good management brings about order and stability by formulating plans and objectives, designing structures and procedures, monitoring results against plans, and taking corrective action when necessary. Leadership involves recognizing and articulating the need to significantly alter the direction and operation of the project, aligning people to the new direction, and motivating them to work together to overcome hurdles produced by the change and to realize new objectives.”

 

Have you ever participated in a project with a great leader and a great manager? Or on the other hand, have you ever participated in a project with a poor leader and a poor manager? What were the results?

Establish an Organizational Culture that Supports Projects

I read a great article from Business Improvement Architects: 

http://www.bia.ca/articles/HowToEstablishaProjectManagementCulture.htm

 

The article neatly describes the problem with the current way organizations handle projects and how the cultures are evolving to have committees to steer the projects in the right direction. The article states the problem as, “Projects are becoming a critical part of corporate success yet research tells us that most projects do not fully succeed. According to the 2004 PriceWaterhouseCoopers Survey of 10,640 projects valued at $7.2 billion, across a broad range of industries, large and small, only 2.5% of global businesses achieve 100% project success and over 50% of global business projects fail. The Chaos Survey by The Standish Group reports similar findings. They say that 71% of all projects are either “challenged” (due to late delivery, being over-budget, or delivering less than required features), or “failed” and are cancelled prior to completion or the product developed is never used. Their statistics have not effectively changed since 1994.”

The article continues to site how the support of the organization was one of the main predictors of how a project would turn out as either successful or failure. The article states, “Business Improvement Architect’s 2005 project management research of over 750 organizations world-wide shows that 60% of Project Management Offices (PMO) say that the organizational culture is not supportive of the PMO. The major reason for project failure is that most organizations do not ensure that all projects they implement align with their organization’s corporate strategy”. Once companies are able to implement an organization culture that supports projects, the organization is able to experience the following benefits:
Projects will be aligned with corporate strategies, ensuring that business objectives are met.Projects come in on time, so your time to market is improved.

Projects come in on budget, potentially saving millions each year.

Projects meet customer expectations so customer satisfaction levels increase.

Project teams are more effective and efficient, leading to high morale and more dedicated staff.

How has your company supported one of your projects? How does their support or lack of support contribute to the success or failure of the project?

Form versus Knowledge for Project Managers

I selected Dr. Safarians to be the person for my interview for various reasons, and I am very happy that I did interview her. She was a project manager at the time, but her presence and knowledge was intimidating. She was speaking to my boss’s boss at the time and I happened to walk into the room requesting an approval on a protocol when I caught her discussion on her current project. She left a lasting impression on me, and I have respected her ever since.

Dr. Safarians had been promoted many levels in the past 9 years since I met her first. She had become a Director of Implementation. It is hard to describe what exactly this role does, as it is very complex and ever evolving as the realm of her responsibility changes, but it is a cross between a Director of Operations, Project Manager and Program Manager.

What brought Dr. Safarians into project management is that, “everything is a project, the only difference is the scope.” One of the items that she mentioned is that in undergraduate you learn about the projects and findings of others. You learn how others worked through problems and how they were able to solve the problems for others to grow from to lead to other discoveries. In graduate school to learn how to think for yourself to make those discoveries for others to learn from. Dr. Safarians earned her doctorate so that she could have the creditability to work on of her choosing projects and to demonstrate that she is a source of authority on matters pertaining to her field of expertise.

Her educational background has helped her because she can give substance to the project. Dr. Safarians stated that, “project managements have to be masters of form, not necessary knowledge. Project managers give the form to the discussions and schedule’s, they give shape to the deliverables. They do not have the technical side. They need to become technically savvy to understand. A project manager that manages to the schedule are not able to facilitate to the project.” With her knowledge she is able to embrace constructive discussions and understand the various perspectives of an issue in the project to give a better solution to a problem, or break down a barrier.

            There are two points that I would your response to. The first is, has your journey to get your MBA helped you gain credibility in your job when it comes to making decisions, and if so how? The other is, the discussion about form versus knowledge. I have worked with project managers that have facilitied and have lead, and only after interviewing Dr. Safarians did I realize that project managers do not always have to be the point of author or decision making, they can be guides or intermediates for knowledge. What are your thoughts on form versus knowledge?

Recovering Lost Time

I recently ran into a situation in the current field project that really set back my promoting of the event. Almost two and a half weeks ago, I reached out to the human resource department of my company to first confirm that I am allowed to advertise and promote the event and the charity. Secondly I wanted to see if I could generate donations by hosting a jeans day for those that donated. And lastly, I wanted to see if the organization would help sponsor and contribute or match the funds raised from the jeans day to help out the cause. At first a week went by so I decided to follow up with the HR person that I forwarded the request to, she confirmed that she had passed along the email to two different parties in the company, one to the HR personnel that helps to facilitate social events such as this, and the other to the secretary department of the company executives to gain approval. By the second week, I followed with my contact and was simply given the number to the HR personnel and I could sense that something was wrong. I contact the person in charge of social events and was told that the company would not be able to help support the cause due to potential liability reasons.

This was highly disappointing, but even worse was the all the time wasted in waiting for the organizations response. In order to pick up the pace and get back on track, I reached out to the internet to search for the best ways to recover the lost time and progress forward. I found many articles to have some really interesting tips, but also realized that not all strategies were feasible or applicable. I have listed a few that were on almost every list and that I consider to be the most helpful:

  1. WORK OVERTIME:  It’s not the most ideal suggestion, but it is the most logical one, especially in a time crunch. If you work more hours, you can get more done. Just like any work detail or school assignment, when you are hard pressed for time, you typically work long hours non-stop to reach your mark.
  2. REDEFINE PRIORITIES:  A strong project manager has to be aware and on top of everything that is going on. It is even better to be able to anticipate setbacks and mitigate risk. Once the project manager identifies that an output is not proceeding in a timely fashion, he/she should be able to go back to the drawing board and start considering what changes the can make to the scope or the critical path and still receive the end result originally desired.
  3. REALLOCATE RESOURCES: Once the project manager is aware of the deficiency in time, he/she must take a step back and re-prioritize the schedule. When done, the project manager can see if there are any available resources they can pool from the activities that are not on the critical path to help resolve the issue. These resources can be either tangible tools, software, funds, or human capital.
  4. REQUEST ADDITIONAL RESOURCES: If at all possible, it would be great if you can get more money or more time. One way to do so is to evaluate your budget and see if there is any wiggle room. If not, it could be worth a shot to bring your issues to the stakeholders, with properly detailed results, appropriate the problem, and devise a well-defined solution that can be solved with the resources you are requesting. The request has to be reasonable, and the problem should be dyer enough to gain the attention it deserves.
  5. COUNT YOUR LOSES: If all else fails, the project manager needs to be able to take the hit and count its losses. In certain situations, what’s done is done and there is no way you can extend the deadline. In those cases you just have to accept the time wasted, restructure the time you have left and make the most with what you have. If you are proactive and productive enough, you can make due and possibly get to s result without anyone even knowing about your hiccup.

I hope these suggestions are helpful. Please feel free to weigh in on your thoughts, techniques that have worked well for you, and even share the ones that have not.

 

http://www.techrepublic.com/blog/10-things/10-ways-to-get-a-slipping-project-back-on-track/

http://cobaltpm.com/5-ways-to-recover-from-a-project-setback/

Managing Up when faced with challenging projects

The most challenging projects we are often assigned are projects that come from the executive leadership.   In situations like this, we are often told that we must manage up to deal with these difficult scenarios.   Managing up always sounds much easier than it really is and I think the principles of managing up are pretty straightforward, but they can be difficult to perfect.   The article “Program Management: Learning to Manage Up, Outward, Sideways and Down” (link below), describes some of those principles on how to manage up and beyond.

The article lists the three key elements of effectively managing up: use your meeting time wisely, always come with an action plan when you have bad news, and always be honest.  In general, these are pretty simple principles.  But following through on those principles can be more difficult than expected.  Personally, I do my best to manage up to my boss and my executive leadership team but sometimes I feel these principles are not enough.

I have found that understanding the agenda of a project can go a long way and sometimes you have to know that you’re not going to win, even if your argument is completely logical.  I often wonder if their unrealistic expectations are a way of pushing the team further or simply a misunderstanding of what is possible.  I find this is where knowing each individual can be effective.  If you know what drives the individuals you are more likely to get insights into why the certain project or scenario is being push forward.  But, this is also where trust can come into play.  If your boss or executive team trust you, they are more likely to be honest and provide full disclosure, so you don’t have to rely on your gut to tell you what is going on.

But if full disclosure is not possible, this is where managing sideways can be helpful.  As the article describes, managing sideways is getting “each manager’s full ‘buy-in’” in order to see a project through.  Sometimes when you can’t manage up, managing sideways is enough to help see the project through and ensure that it is not completely derailed.

In many situations I am in a situation where my executive leadership team is also my client, which means I must up and outward with the same team of people.  Sometimes this is easier, often it can be more difficult.  When the client sets the priorities for the team, priorities can become skewed as to what is best for the company and bottom line.  There’s no balance to ensure each project is really in the best interest of the company.  Managing down is always critical to the success of each project and is generally easier than managing up.

Have you found yourself actively managing up?  How many levels up do you manage?  What are the most effective tools or techniques have you found to successfully manage up?

http://evolvingstrategies.com/program-management-learning-to-manage-up-outward-sideways-and-down/

When happens when your project fails!!!!

The past few weeks have been a world wind.  Going from being really optimistic about a project and feeling good about the amount of planning and risk mitigation seemed to spell success early on.  We even restructured the timing and resources to accommodate the needs of the project on the fly with stunning success.  After looking at the risk plan and the projected final milestone, I saw something really bad in the way.  The need for untested and invalidated software to make the entire project successful.  I thought I had the resources to mitigate this risk.  I though the project had the visibility to make proactive changes in code when required.  I was wrong!!  Not only did I fail to get validation on the fix in the lab, I relied on a senior architects word that he has resolved this for other customers in a way that is within our scope of work.  The interesting part was the resource going silent during the project and making requests of his schedule early on placing the project at risk.  Why didn’t I ask for Proof?  Why did I not ask for references?  I guess I trusted the source and that was the risk I should have identified.  Even more, I relied on a host of individuals that happened to disappear once the project became critical and needed their update.  It could suggest one or two things.

  • The experts where feeding me incorrect information and really did not understand the project.  I immediately dismissed that claim due to several meetings with detail explanation of the problem and needed outcomes.
  • The played the white night.  That is a term I used to identify people that want to come in and save the project.  They also want to make sure they are the resource choosing for the project.   At first I dismissed that thought, but had o consider it after some continued research into the problem.    What do you do when failure is an option?

I considered folding and allowing he project to just fail.  That sounds bad, but sometimes there are no logical work abounds that are immediately viable.  In addition, we rely heavily on the product group to define a roadmap inclusive of these changes to benefit these types of changes.  I was in a real pickle.  The status report had a red maker on the key milestone.  My risk plan was now front and center.  It showed the theoretical failure as a real potential.

After some more searches, I found a ray of light.  What if the risk of failure was in the plan and it caused us to redirect efforts toward an alternative.  Luckily for me, this approach allowed me more time to research additional experts in this field.  It also allowed me to meet with product engineers who actually had a release coming.  I was fortunate to find an outcome supporting the actual risk that was defined in the plan.  I was also willing to allow the project to fail which seems incorrect.  Sometimes failure is needed to reach the ultimate solution.  It worked this time, but it was part of assumed experimentation that allowed me to take this road.  If this was a more aggressive project around a current product, I believe this would not have been appropriate.  Have you let a project fail?

 

Too scared to tell the truth

I am sure most of you have witnessed at your organization or during your tenure as PM on a large, visible project, the reluctance to pass bad news to you or your PM until things hit the ceiling. As a PM , nothing is more scarier than not knowing the real status of the project until when the deadline appears. I was interested to know, what should the PM do to encourage team members to report back honest status to the PM and above. I found this interesting article in LinkedIn that talks about just this topic.

https://www.linkedin.com/today/post/article/20140516192953-58518848-why-executive-management-doesn-t-get-bad-news-until-it-s-too-late-to-do-anything-about-it

According to author following are some of the ways that PM’s can deal with this issue

1. Don’t shoot the messenger- Encourage team members to be forthright about issues and risks that they see to timelines. The attitude of PM should be that of a shared responsibility (we are a team), rather than threaten team members.

2. Meaningful status meetings- Status meetings should be more of a question answer session rather than the usual “what is the status and blockers” line. Advanced (specific) questioning on individual deliverable will yield more than the “it’s all OK boss” response.

3. Understanding the technology – Knowing a little about the underlying technology implemented in the project will help PM’s do some advanced questioning or additional probing of individual deliverable. In my opinion, this will also help the PM’s to be more tightly integrated with the team. I know some PM’s that prefer to stick to scheduling and plan management and they end up siloed.

4. Each milestone is a project – The author in the LinkedIn article recommends to treat every duration between milestones as if it were a project in itself, with the upcoming milestone as the terminal date. This minimizes the tendency for people to think they have plenty of time to make up for schedule slippage and budget overrun.

As one of the comments on the author’s article sums it up – This takes a kind, humble, yet confident and assertive leader. Employees won’t be scared of the PM’s wrath, but will rather not want to disappoint the PM.

How do you engage peers and team members to be honest and proactive in communicating risks about the project?
How do you coordinate and communicate bad news about the project to your superiors?

 

Analysis Paralysis

This first sentence took me 20 minutes to write, no seriously.  Does this ever happen to you?  How about the term paper (project) that you spend 8 hours doing, but actual typing time is less than a hour?  Why does this happen and what can we do to avoid ANALYSIS PARALYSIS.

For the sake of this blog post, we are looking at analysis paralysis through the lens of a project.  It can be any kind of project including a term paper, a home remodel, or something at work.  The initial parts of all these projects are the ones that give most people the most issues.  So how do we avoid them?

1.  Set the timer

Have a pre-defined amont of time  you will spend on gathering the data you need to do your project.  Once that time is up, it is time to start doing.  No matter how much of an expert you become, there will always be details that you will not be able to know, it is just time to accept that.  This will also help your organize what is really important, and what is not.

2.  Grab a template 

Have a template that you have had past success with and continue to use it.  I do a lot of ad-hoc projects covering many different topics.  I have found that if I use the same format/template for my memos, I can more quickly organize my thoughts.  For example, my typical writing will be organized in this order: top 3 takeaways, background, analysis, conclusion.  Sure there will be differences between different work, but having a template allows you to focus in on the important areas.

3. Stick to the basics and trust your gut 

As I have written in a lot of my comments for these blogs, I am a firm believer that simpler is almost always better.  When people try to make things overly complicated or difficult, it takes them out of their comfort zones, and ultimately could lead to failure.  Gut feelings are typically right, no really.  Famed scientist Gerd Gigerenzer has written “intuition, it seems, is not some sort of mystical chemical reaction but a neurologically based behavior that evolved to ensure that we humans respond quickly when faced with a dilemma.”

4. Let your team help

We have talked about this in class over and over, but it is important to mention again.  When working in a team, utilize all members.  This could significantly reduce analysis paralysis.

5. Take the leap

Just go for it, every project is going to have issues.  Accepting this fact, and understanding contingency plans ahead of time will make taking the leap much easier.

 

These different steps will help limit the time it takes to get a projects rolling and avoid the trap of analysis paralysis.

 

Sources

http://www.projectsmart.co.uk/the-paralysis-of-getting-the-project-started.php

http://www.reliableplant.com/Read/18128/analysis-paralysis

 

Fun with Agile…Really

Hello Folks,

Welcome back to another episode of “Exploring Agile”. Today we will be taking advantage of the universally loved YouTube.  While I will admit that this cartoon is no Conjunction Junction, it does a nice job of simply conveying the Scrum version of Agile Methodology.  The video is eight and half minutes long, with the last minute and a half being a plug.

https://www.youtube.com/watch?v=OJflDE6OaSc

For those of you not willing to invest the seven minutes, I have provided a brief outline of the content;

Reasons to use Agile;

  • Focuses on prioritized customer value
  • Mitigates risk by involving customers during incremental development called Sprints
  • Minimizes Time to Market
  • Promotes Certainty or Deliverable Confidence
  • Increases Revenue

Project Management Agile (Scrum) Process;

  • Create a Product Backlog comprised of;  User Story’s (user/customer needs)
  • Hold a Sprint Planning Meeting (Scrum Master and Project team)
    • Reviews User Story’s and inquires about additional pertinent details
    • Prioritizes User Story’s from Project Backlog to create a Sprint Backlog
    • Hold Daily Stand-Up Meetings to status;
      • Yesterday’s activities
      • Today’s activities
      • Current Obstacles and Roadblocks
      • Records Progress in Sprint Backlog
      • Charts Progress on a “Burn-down Graph”

      End of Sprint Review Meeting – Present completed deliverables to customer

      Launch Sprint #1 Deliverables

    • Conduct Informational Interviews to get
      • Feedback
      • Missed deliverables
      • Desirable Enhancements
    • Sprint Retrospective Meeting
      • What did or did not work well: identify areas for improvement
      • Start the Process again

Best Project Management Practices- Short and Sweet

We have covered interesting set of topics about project management, best practices and top issues. While there may be many things that can be listed about best practices, I came across an interesting article that basically summarized project management in 10 key best practices.  I found the article to be on the point, easy to grasp without getting to too many details. Below are top 10 practices:

  1. ” Plan the work by utilizing a project definition document”- It is often that people just want to jump into projects without following proper project protocol including documentation. Project documentation is one of the keys of successful projects since it lists key components of the project including timelines, sign offs, plans, etc.
  2. ” Creating a planning horizon”- Planning horizon includes work plan, resources, costs which are necessary part of the project.
  3. ” Define project management procedures up front”- It is critical to define the procedures with all of the stakeholders and work stream owners. When things are shared up front and people are held liable, it creates structure for all involved parties.
  4. ” Manage the workplan and monitor the schedule and budget”-  It is important to keep the work plan updated with latest information including the budget.
  5. ” Look for warning signs”- It is important to be on top of the deliverables. Any sign of deadlines not being met or costs being above the norm needs to be immediately addressed.
  6. ” Ensure that the sponsor approves scope-change requests”- Scope changes are part of projects, but all changes need to be approved by those seeking to make them. It is necessary to keep the documentation as any scope changes made affect timelines, resources, costs and everyone needs to be aware of it.
  7. ” Guard against the scope creep”- Scope creep is one of the common issues in the projects. It is important to be very protective of any scope creep as that could be one of the causes of projects not being done in time or budget. Scope creep can be made of many small changes that amount to big impact on the project.
  8. ” Identify risks up front”- Critical to identify all risks upfront as possible. When you are aware of the risks, you are more equipped to plan dealing with those risks.
  9. ” Continue to assess potential risks throughout the project”- It is important to not just identify risks up front, but keep on top of any risks that may take place during the project.
  10. ” Resolve issues as quickly as possible”- Tracking and resolving issues on time is a critical part of Project Manager’s job. Issues will arise, but they need to be immediately addressed.

While reading the best practices, I found myself basically either faced with same issues and being able to deal with them or learning now how to best address them going forward. Do you have list of your best practices? How did you come up with your list? Was it shared with you or did you create the list due to your own experience?

Source: 

http://www.techrepublic.com/blog/10-things/10-best-practices-for-successful-project-management/