The Three Ships in Fleet of Success

Kerry Wills writes in PM Hut:

I believe there are three ‘ships’ that are essential to be in your fleet of success. I am not talking about the Nina, Pinta and Santa Maria. I mean the following three essential skills:

1. OwnerSHIP Ownership means truly feeling accountable for the work and projects you are on. This means not just focusing on a particular task and hoping others will do theirs. This is genuinely owning all work even if you are not directly responsible for it.
   
   
2. StewardSHIP
   Stewardship means caring about your work, the project and the company. Being a good steward means doing the right things for the company, growing the people around you and looking to improve things that are broken.
   
   
3. LeaderSHIP
   Leadership is the ability to motivate and influence others to meet common goals. It also means being a champion for your team and supporting them.

I don’t see how a project manager can be successful without all three. If they don’t feel ownership of the project or stewardship to the organization, then there will be oversights and missed commitments. Without leadership, the team won’t be successful or feel motivated to do the work and key stakeholders won’t be influenced on key decisions.

Influencing Senior Project Managers

How do you change a stubborn senior manager's mind? For example, he or she might claim your project only needs six weeks to complete, even though you have a carefully researched and resource-loaded schedule that proves 10 weeks is needed.

Arguing won't work. In fact, given the power structure, arguing will simply put you in a worse position. Doing nothing simply delays the problem and you will eventually be held accountable for your perceived failure to meet the stakeholder's unrealistic expectations.

To change a senior manager's mind, you need to change the manager's expectations. Though you may battle a heavy overlay of skepticism, use of effective communication and a planned strategy should do the trick.

Effective communication requires that at least two of the following three elements be present:

•    You're known as a technical expert.
•    You're credible: People know you provide reliable and accurate information.
•    The information you're communicating is relevant to the receiver.

Influencing a skeptical senior manager requires you to boost all three facets. You cannot do this alone. Some options to consider include:

Co-present your case with a trusted source. You increase your chances of success by sharing the stage with someone the executive trusts. Build the value of your ideas on the credibility the co-presenter has established with the executive.

Demonstrate endorsements to build power. Ask others in positions of power to let the executive know they support your idea.

Stroke egos and use the executive's credibility. Authentically move ownership of "the" idea -- not "your" idea -- into his space. You can do this by using phrases such as "You've probably seen this data already," or "I'm sure your analysis has shown similar results."

These approaches need organizing and take time but are essential if you are going to effectively advise upward. 

Article by Lynda Bourne for Voices on Project Management

Agile Methodologies not the answer to all Projects

Kiron D. Bondale in an article for PM Hut explains:

The allure of agile is seductive – an organization tries it with one or two projects, experiences greater success than they’ve achieved historically with waterfall approaches and decides to apply this new methodology to all projects. The risk is that when they hit a project that was not well suited to agile methods, the temptation to throw the baby out with the bath water is compelling and they revert to their previous approaches.

So what are some criteria that might rule out the use of agile methodologies?

• I’ve written before about the importance of trust on projects and this affects agile projects to a greater extend than waterfall ones – environments with low levels of trust might be better suited to traditional approaches where rigorous (though onerous) decision & deliverable sign offs and change approvals could reduce the likelihood and impacts of finger-pointing.
• Projects where real-world constraints prevent the ability to re-factor components or to refine requirements through an iterative approach. When one is laying a building’s foundation, you usually only get one chance to do it right and the costs of rework are significant. This is not to say that construction projects can’t benefit from agile approaches (especially during the creative or design phases), but their utility will be restricted to those work packages that can support progressive evolution.
  
• Projects that impose significant “hops” between the customer and the delivery team. This has nothing to do with geographic distance – there have been many successful virtual agile projects. The issue arises when requirements are distilled and translated multiple times from the customer to the team members. The likelihood of miscommunication and rework increases to the point where a traditional approach might yield better results with less effort.
  
• Minimal or no change is expected to the requirements. If a project’s needs are very well understood by both customer & team, a traditional waterfall approach may be a better fit. A good example of this could be an application upgrade driven by the need to maintain vendor support (as opposed to re-engineering business processes).
  
• Time-sensitive projects with project teams or customers that have not used agile methods before. As with any methodology change, the first time a practitioner experiences it, there is a resulting loss in productivity as they come up to speed on the new methods. If there is a deadline looming, sometimes tried and true approaches (though less efficient) should be employed.
  
• Industries where strong external regulatory requirements drive the need for heavy artifacts or strict adherence with well documented processes. While agile methods can be used during research or analysis phases on such projects, product development and manufacturing phases in such domains are forced to use waterfall approaches to satisfy these compliance needs.

Agile is a way of thinking and once can find a way to apply agile principles in almost all projects but agile methodologies are not a universal solution.