Project Management Mentoring Tips

Control also means enforcement. Ideally, processes should control the people performing them, not the other way around. Whether it is for adopting best practices, compliance, or simple efficiency, an ad hoc approach makes it difficult to repeat desired outcomes. When analyzing processes, consider how the processes themselves can contain built-in metrics and reporting to notify decision-makers when their processes are out of alignment.

Risk Responses and Spies
Here’s a pop quiz: quick, what are the four types of risk responses? If you have trouble remembering, here’s a simple mnemonic suggested by one of our students. During World War I, there was an infamous spy who worked for the Germans named Mata Hari. That was her spy name, but her first name, “Mata,” is the mnemonic to remember the risk response types: M = Mitigate, A = Avoid, T = Transfer, and A = Accept.

Since spies are “risky” to deal with, maybe the famous spy Mata Hari can help you remember the four risk responses! To learn more about risk management, attend our course on Project Management Fundamentals. To receive a free risk planning template, please write to us.

Just when you think your job, business or industry is doing new or innovative things, a reminder comes along that its not quite so new as you think. The 16th century Japanese military strategist, Mushashi Miyamoto in his book “Nine Precepts of Mushashi Miyamoto” wrote nine guiding principles. His first one is “Do not think dishonestly.” Seems pretty obvious, doesn't it?

But, in project management and requirements analysis work, there are several applications of this wonderful precept.

1. Don't say “yes” to a project request if you really mean “no.”
2. Don't agree to a fixed project deadline if you know it can't be met.
3. Strive to understand client requirements completely. Probe deeply until you really understand and don't pretend to know more than you do.
4. Provide honest status reporting in tasks and deliverables.
5. Make sure all scope change requests go through a formal process; don't think you can just “sneak it in.”

Project success depends on many things including the skill of the PM and team, clear and correct requirements and client involvement. A universal ingredient for all successful projects is sponsor involvement. Research by organizations such as the Standish Group and reports by the Center for Project Management, consistently show that an involved and supportive sponsor is crucial for project success, no matter what the size.

Because sponsors come in so many different varieties, it’s difficult to offer general advice. One constant across all projects, though, is the need for and the value of a project charter. This is a short document sanctioning the project and articulating its vision of what it should produce. Preferably your sponsor should write them, but at the least the PM should ghost write them and get the sponsor's approval.

If you'd like a charter template to help you get started, send us a note.

Projects can't succeed without the commitment and involvement of the customer for whom the project serves. According to the Standish Group's latest Extreme Chaos Report, the number one factor contributing to successful projects is what they call "user involvement." In their previous report, this was the second-highest contributor. Clearly the time spent by customers on projects is paid back by better results. Executive support has also been a prime contributor to success.

You may be thinking: "That's fine, but how can I as a project manager or business analyst convince my customer to spend the time?" First, it's up to the project sponsor, and not the PM or BA to get and keep the involvement. Work with your sponsor and make the case to get the time commitments you need. If those commitments are slow to happen, point out the risks that will occur if adequate time is not spent in the requirements discovery phase. Ultimately, the final product will not meet business needs and will be scrapped or reworked if requirements are not captured and analyzed enough.

One of the significant barriers to requirements elicitation is the lack of trust between key clients and the business analyst or project manager. Trust usually takes time to develop. We may initially trust or mistrust those involved on our projects, based on past experience, personal filters, culture (organizational, geographical, and otherwise), and a wide variety of factors that can influence our judgments. Analysts and project managers don't always have time to let relationships develop.

One thing that can be done to build trust is to communicate bad news. If the project is behind schedule or needs more resources or if lack of stakeholder participation is slowing the project, it is important for project managers and analysts to address these issues with the sponsor and other appropriate team members immediately.

The Project Scope Statement is a living document. Your Sponsor should know that the milestone dates are subject to change until you have finished your detail WBS planning. THEN, you manage your project to the WBS based dates, and resource commitments associated with them. Update the Scope Statement with any new milestone dates.

Always know who your key stakeholders are, and form a good, trust-based, partnership with them. It will pay dividends, such as, scope clarity, a higher quality product, and a desire to help make the project a success.

If you want high quality task estimates, good Work Breakdown Structure (WBS) planning is essential. Take each deliverable in your scope statement and break it down to its lowest level work packages. Define activities for each work package. Look at each activity to see if you can break it down into lower level tasks. Then make estimates for actually doing the work on each task or activity (if it can't be broken down any further). The resulting estimates will be more accurate with this approach than with any other.

Good communication is essential for project management success. It is the 'oil' of the project engine. At a minimum you need to create a communication plan that identifies all the key stakeholders, what information they would like to receive, when they would like it, and how they would like to get it (meeting, e-mail, status report, etc.). Following through on this plan will help your project succeed by minimizing surprises, allowing key stakeholders to easily react to what they are interested in, and ensuring that no one is left out. 

Paying close attention to project risks is an important ingredient to project management success. You should be identifying, quantifying (probability and impact), and defining how you are going to deal with high level project risks during Scope Statement preparation. Once the project is underway have your team help with other risk assessment (ID, quantify, plan for each risk), and then review/update the risk list at least once a month. This basic Risk Management process will payoff when you see how follow through on your risk plans has avoided a risk, mitigated the probability or impact of a risk event, or just provided the team with a plan in the event a risk event happens.