Author: Alicia Trelles-Duckett

Two years ago I was deploying a high-technology project for a client. It was a worthwhile project, whereby we were going to give sales people the ability to communicate instantly with their developers in Asia. A few weeks into the project, the client’s own Security organization became very interested… and proceeded to shut us down!

We have written a few times in this blog about the importance of understanding a project’s justification, or business case, before plunging into planning and implementation. Why is it important that this project be deployed? Why now? What are the essential features needed? Who is the ‘management sponsor’ interested in seeing the project succeed? What we don’t discuss as often, but can also be critical –as illustrated by our now defunct project− is an early Stakeholder Analysis.

Stakeholders are people (or organizations, such as the aforementioned Security) who are involved in the project or who are affected by the project. When we mention ‘stakeholders’, it is quite easy to limit ourselves, and just think to include the performers and the customers of a project. In truth, we must look further afield and consider other indirect persons or groups that may not be as obvious, but who are still being impacted by our project. For example:

1. Customers of the customer – It may be that the ultimate user is not the group who commissioned the project, but customers of theirs who have additional needs. If the project’s ultimate customer may or may not speak English for instance, we may want to include symbols along with written instructions, to increase clarity.

2. Regulatory Groups − Our analysis should incorporate functions which may not be obvious, but who would indeed have the authority to terminate our efforts. They can reside in the customer’s organization or in society at large, eg, Procurement, Security, the city’s Health Department, Fire Department.

3. Managers of our resources − We should stay in touch with those who manage key individuals in our project. They may have their own set of measurements, timeframes or constraints and possibly impact someone’s availability while we still need them.

There are others of course. By introducing these categories though, we hope you can manage direct and indirect stakeholders’ expectations, and avoid unpleasant surprises.

—————————

For more resources, see the Library topic Project Management.

—————————

Our topic today has nothing to do with an eccentric or detestable person, happily. Although some project managers may not agree, a more prevalent pest to be avoided in projects is “scope creep”: additional scope that creeps in, without anyone in the project team noticing. Before you know it, there is an expectation that the project will indeed deliver this additional scope, leading to extra stress on your resources and your timeframes. At the request of students who have often asked for suggestions, here are four strategies I have found useful in the past to ‘avoid the creep’:

1. Change Control
Assuming the project scope has initially been agreed, the best option to avoid the dreaded scope creep is vigilant change control. This involves (a) keeping a change log for the project which is stored in the same repository as other important project plans; (b) timely assessments so that each Change Request is settled in a reasonable amount of time; and (c) discussing the change log with customers and performers at regular status meetings.

2. How About ‘No’
Sometimes it is difficult to perceive that a change has just been introduced into the project environment, as it may be framed like an innocent question. Example: “Surely this training can be translated and taught in French when we install the Morocco location?” Someone in the project team, probably guided by a lecture they heard on “Delight Your Customer”, answers “Yes, I’m sure we can manage”. Scope creep alert! Instead, the project manager might try jumping in, with some variation of ‘No’. Good examples: “I wish we could”; “I don’t think that’s in scope”; or (one of my favorites) “Our budget is already so stretched”.

3. Train the Project Team
There are a few steps and processes that your project team will have to be trained on during the project. Why not make “Change Control” part of another topic, and use this discussion to make them comfortable with the statement “We’ll be happy to do an impact assessment on that change request”?

4. Better Late Than Never
Maybe, and in spite of your best attempts, a crafty customer may get a project performer to agree to the extra work. We should remember that good project management is about progressively elaborating plans, and re-opening any items which now need to be discussed, even if they were previously closed. In the case of the extra work, we could say, for example: “I know Bob had been trying to accommodate this change but, regrettably, we don’t have the funding to do it. Let’s open a change request ”. Better to reset the customer’s expectations a little late than to make the project miss its agreed timeframe and budget. So let’s actively avoid that creep.

—————————

For more resources, see the Library topic Project Management.

—————————

Here is a familiar scenario for some of us who perform projects for customers: a request for some work comes in. We have (or know where to get) the capability, the skills the personnel. Having performed similar work before, we even have references. The catch? Geography. Either the customer, or key performer(s), or the project manager is in a different geographical location. And unfortunately, some stakeholder becomes entrenched in the position that everyone must be co-located. So the (questionable) travel/commuting commences in earnest.

Too many projects suffer from this excessive travel or commuting, when they could be leveraging Virtual Teaming tools and techniques. Too many checkpoint meetings; testing sessions; status meetings take place where the obsession that everyone must be present prevails. I find incredibly worrisome when some of these project resources, very often managers, brag about having back-to-back trips in which they take overnight, red-eye flights in order to make it to their next meeting. One would think that, rather than brag, the person would be embarrassed that poor planning, or automatically agreeing to this excessive travel, has left them in this position. So instead of automatically agreeing to all this costly, unproductive travel, next time suggest a concerted effort to incorporate more Virtual Team behaviors into your project:

1. Leverage Internet, IM virtual teaming tools
Where to begin, honestly! There are so many Instant Messenger, Videoconferencing, Web seminar tools available today. There are even free collaborative tools such as, for example, Google Docs, where multiple team members can be updating the same document at once and you don’t even have to fight the frustrating document ‘check-in/check-out’ of certain other document repositories.

2. Share information profusely with the project team
The more information team members have, the less they have to request it from others. Hopefully this will also lead them to decreased unproductive travel.

3. Promote project team as a ‘Select Club’
Give the project a name. Have a logo. Schedule invitation-only web seminars. All these things increase the pride of the project team in belonging to this ‘select club’. Rapport and trust among team members increases and they tend to watch out more for one another, again, decreasing needless travel and commuting.

4. Don’t let them disappear
During conference calls, present the achievements of all, even if they are not attending. Especially achievements of team members in other countries. This reinforces continuity and cohesion among the project team, so communication becomes more natural and not a big deal.

5. Develop a culture of keeping commitments
Agree with your team the ground rule that, if we make a commitment, we keep that commitment. This is the best way of fostering trust. When individuals and organizations trust each other, transactions are automatic and cheap. It is when there is no trust that we start needing all the cumbersome documents, caveats, contracts and, oh yes… the excessive travel.

—————————

For more resources, see the Library topic Project Management.

—————————

There are certain skills which are incredibly useful for small businesses. If the business has someone on staff knowledgeable about ‘accounting’ for instance, or ‘taxation’, better decisions can be made consistently in those areas. For example, business equipment would be purchased knowing already in advance what kind of depreciation will leave the business in a better tax position.

If the business performs projects for customers, the same is true for the skill of Project Management. Small but important project management concepts can be the difference between a profitable or an unprofitable project. Let’s say that the customer wants to add items of scope to the project. What would be the correct response, according to tried-and-true project management methods? If the time duration of the project needs to shrink, what would be the best course of action, and still be successful?

Most of us have heard the adage “the customer is always right”, or “we must delight our customers”. But in businesses which perform services, one must be very careful and qualify these statements with some limits. Otherwise, we could find ourselves delivering a project with unlimited scope and unlimited liability!

Recently, a new and easy tutorial has been released for just this purpose. It is a video made specifically for professionals whose main job is something other than project management, but who must still perform projects for others. Without using complicated project management jargon (such as “Earned Value” or “Project Charters”), and in plain conversational English, this video walks a person through the stripped down, absolute key concepts for delivering projects successfully. Such that the projects end up with win/win outcomes: the customer walks away happy with his/her priorities fulfilled, and the small business walks away with profits in the bank. The details on how to get this tutorial can be found at www.theartisanpm.com . Check it out. So far, every small business which I have heard got it, has improved the delivery of their projects.

—————————

For more resources, see the Library topic Project Management.

—————————

Recently, an acquaintance who owns his own business installing industrial valves, remarked how difficult he thought the field of Project Management had become. “Why is there so much paper?” and “Why do the concepts have to be so hard?” (He does have a point, what with Earned Value Analysis…) He indicated that if it weren’t for these hard terms and all the trappings, he would take the time to learn a few concepts and run his projects better. So here goes a simplified version of Project Management, without ‘all the trappings’:

IN THE BEGINNING
Although our first impulse may be to start planning right away when to do what, don’t. Step back for a moment. Get an understanding from the person sponsoring and paying for the project about what they hope to accomplish. What’s the purpose? What’s the motivation for it? Why now? Hopefully there will be strong answers to this kind of analysis. A very few times in my career, after analyzing the business case, I have seen that the assumptions require an astounding amount of good luck. I have told the client so, at which time he has chosen to save his money.

THE TRIPLE CONSTRAINT
But hopefully the justification or business case does indeed pass muster. What then? You may have heard of the ‘triple constraint’ as applied to projects: it means reconciling a reasonable amount of scope, with a reasonable timeframe, for a reasonable cost. It is iterative, and we usually have to do a couple of laps discussing all three topics, until we have an agreed triple constraint. Who should be in this Scope-Time-Cost agreement? Ideally the project sponsor, the project performers, and those who will use the result of the project (a.k.a. users). Don’t forget to write it down and circulate it to these audiences. And any time the project starts diverging from the original agreement, discuss and agree a new triple constraint. Of course, there is other planning we could do in important areas, such as risk and communication. But today we are doing the pared down version, remember?

PROGRESS, PROGRESS
If a balanced triple constraint has been reached, we can start implementing the project. But we can’t just hope that, with a fair wind, the work will materialize in the timeframe we had hoped for. We have to actively track it. Yes, I know we are expending hours every week, but are we actually achieving what we agreed, when we agreed? If we are not, renegotiate once again a new triple constraint. And hopefully this one will not require as much fair wind.

—————————

For more resources, see the Library topic Project Management.

—————————

When I started my working life, at IBM, years went by before I had any sub-contractors as part of my project team. We could handle just about every request with in-house skills. Alas, almost 20 years later those days are gone, and the opposite has become the norm. It is nigh on impossible to deploy a project without the active participation of sub-contractors, often in key roles. Companies now concentrate on having staff with core skills that will be fully utilized. So for additional projects, or talents, we must routinely turn to sub-contractors.

The current societal change of “collaboration”, facilitated by internet technologies, has also contributed to the rise of sub-contracting. Through various sites we can quickly connect with people who have unique skills, be it for a quick consultation or for a 6-month engagement. This trend of quicker access to specialized skills is good news for our projects. In a business book I read not too long ago, the author speculated that very soon companies will need line managers to actively manage entire departments of sub-contractors, not just manage their full-time employees.

So given that sub-contracting is here to stay for the foreseeable future, what can Project Managers do to make these team members as effective as possible? Here are a few suggestions:

Project Quick Reference Sheet
A one-page summary of key information is helpful. Sub-contractors will probably have different systems for, say, time-keeping or travel expense reporting, so I try to have a list of Frequently Used Sites ready for their first day on the project. A few names of technical and administrative personnel, should the Project Manager not be available, will also help them feel welcome and quickly become productive.

“KPIs” or Metrics
It is vital to get across to our subcontractors why they are needed. What expectations does the project have for them? And not just specific achievements. If possible, we should share and agree with them the rate at which these achievements should take place, even if it is just a range (eg, ‘install three routers per day’). If there is an issue with this rate of achievement, the sooner you know the better.

Progress Monitoring
Often I come across project teams that have done a good job of agreeing metrics…. and then do not follow-up to see if they are materializing. They hope for the best outcome, or trust that because team members are specialists in their field, they will not need supervision. Even if we are managing PhDs in Nuclear Physics whom we can barely understand, we should review progress periodically. A simple checkpoint like, “30% of our time duration has elapsed… would you say you are 30% done with your tasks?” will uncover valuable project information. Then, hope the answer is not too technical, and you actually understand it.

—————————

For more resources, see the Library topic Project Management.

—————————

The following is a guest post by Susan Shearouse, author of Conflict 101.

Early morning, the mists rising off the placid river, the crew racing in that long sleek boat, each team member pulling through the strokes in unison, the team leader sitting at the back calling commands. Ahhh, teamwork…

What happens when the reality of teamwork doesn’t match the vision? The meeting is a little tense, there are several ideas about the best way to proceed. One person starts to speak, another cuts in. A head tilts, a jaw tightens, the voices get just a little bit louder, and everyone in the room stiffens. Fear vibrates through the room – fear that an argument is about to take over, fear that conflict will derail the team and the project once again. Some want to get out of the meeting as quickly as possible, others want to pile on, jump into the disagreement on one side or the other.

What is a project manager to do?

(1) Slow down. Take a break. Allow yourself time to think through a way to proceed. Disagreements are healthy and useful to the team. Better ideas can be created when people can share concerns, ideas and creative solutions. Everyone on the team benefits from feeling that their views are heard and valued.

(2) Take a solution-seeking approach. When and where can we meet? We need a place that is neutral and conducive to hearing one another and enough time for people to air their views. What additional information might team members need? How can we get it to them?

(3) Create a safe place for people to talk. Establish guidelines for the exchange of ideas: stay focused on issues not individuals, listen, respect differences, monitor your airtime, let one person talk at a time…

(4) Be curious. What do others think? And why? Ask questions and wait for their responses. Check that you have understood what they have said – without disagreeing.

(5) Listen. Demonstrate your willingness to hear different points of view without jumping in. Ssshhh – keeping quiet encourages others to talk.

(6) Define the problem. In neutral terms, based on everyone’s views and concerns, develop a common understanding of the problem or question at hand.

(7) Explore options. Create a list at least five to seven possibilities before evaluating any of them. This will help diffuse either/or thinking.

—————————

For more resources, see the Library topic Project Management.

—————————

SUSAN H. SHEAROUSE is the author of Conflict 101: A Manager’s Guide to Resolving Problems So Everyone Can Get Back to Work (AMACOM 2011). She has served as Executive Director of the National Conference on Peacemaking and Conflict Resolution and on the Advisory Board of the Institute for Conflict Analysis and Resolution at George Mason University. Her clients have included Lockheed Martin, Philip Morris, the IRS, the US Environmental Protection Agency, the US Army Corps of Engineers, and many others. Find out more about Susan Shearouse and Conflict 101 here: http://www.amacombooks.org/book.cfm?isbn=9780814417119.

In this blog we talk mostly about project managers and how they can steer the project towards success: how they can start with a strong business justification, do robust planning, enact good change control. But there is another player in the project’s cast of characters who is just as important, if not more, than the project manager. It is the Project Sponsor.

Ultimately, it is in the Project Sponsor’s best interest that the project or initiative be successfully deployed. The Sponsor has, in all likelihood, made a commitment to their own management, to their corporate board, or to an important client. They may even have financial rewards awaiting them, once the initiative has been deployed successfully. So as project managers, we should not feel guilty about involving our Project Sponsors and, in essence, giving them a few items to perform in support of the project’s success. Let’s consider a couple of examples.

Oftentimes, at the beginning of a project, I ask the client for their “Project Charter”. Those of you who have studied the PMBOK® may remember that this is the formal document that authorizes not just the existence of a project, but also authorizes the project manager to start assigning resources to project tasks. Already at the outset we can ask the Project Sponsor to document for us the high-level scope of the project; the resources envisioned; the duration; and the background business case that makes this project a necessity.

Once the project scope has been agreed and assigned, change will probably take place. As part of our Change Management procedures, we should agree with the team that certain levels of change (extra funds, excessive delays, technical approaches) will require the approval of the Project Sponsor. Even if I have been given his authority as Project Manager, I seek the Project Sponsor’s agreement. This achieves two things: (1) The Sponsor could point out different perspectives the project team may not have considered as they address the change and (2) If we have made the Sponsor part of the problem-solving team, he or she is less likely to be unhappy with the outcome. So go ahead and leverage the fact that, in the end, our Sponsor should be the boss.

—————————

For more resources, see the Library topic Project Management.

—————————

As a general rule, project teams will agree with the idea that Risk Analysis makes for a better project. It gives the team visibility of worrisome items, a forum to prioritize them, and some time to react before the risk materializes. So why don’t more project managers incorporate Risk Analysis regularly in their project’s governance?

Oftentimes, the response I hear is ‘lack of time’. A colleague said to me recently: “We already have such limited time to meet as a team, that when we do come together, we have to stay with tactical moves”. Certainly a valid point. But we can streamline as much as possible the Risk Analysis exercise, and incorporate it at the end of a regular Status Meeting once every few weeks (how many weeks will vary — different projects have different risk content). Once done, Risk Analysis might avert problems that would have caused many hours of these “tactical moves” to resolve later.

Here’s how the exercise goes:

• If Risk Analysis has never been done, bring a list of “Risk Categories” to the team meeting (such as organization, technology, infrastructure, subcontractors, logistics, client finances, etc). Of course, categories can be added once at the meeting. And if a Risk Log already exists, bring that to start the discussion.

• Ask the team members: “What are your worries?” regarding these categories. Worries are equivalent to risks. This is your initial list of Risk Events.

• Vote on this list of Risk Events, both in terms of likelihood of each one happening and impact, if the event were to happen. The quickest scale I have found is assigning values of ‘low’, ‘medium’ or ‘high’. So each Risk Event ends up with two scores: one for likelihood, one for impact.

• Write down in a Risk Log only the events that were considered ‘High’ in likelihood and ‘High’ in impact. As a team, decide what would be the best response from the project: a mitigation? a way to avoid it?

• Finally, like action items, each one of these risks is assigned a person in the team to monitor it. So if the risk looks about to happen, this person can alert others and the agreed response would be put in place.

Again, a few weeks later (four? six? eight?), depending on whether the project environment is more stable or more uncertain, we can repeat the exercise at the end of a regularly scheduled Status Meeting.

So go take care of that “Risky Business” in your project and, in the process, look more professional to your Executive sponsor.

—————————

For more resources, see the Library topic Project Management.

—————————