Issue 3 - November 1, 2009

In this issue:

• Ray Posch writes about the project manager's role as relationship manager.
• Elizabeth Harrin discusses new ways of working on projects.
• Lee Lambert asks whether you are using two fundamental tools of the PM professional. Please read this article as if you are PMP certified, whether you are or not.

What Matters Most in Life also Matters in Projects
By Raymond Posch

The other day I came across a recap of one of the most enduring and fascinating research studies ever done on human behavior and the factors that matter in success and happiness. I have read reports on this study periodically over the last couple of decades as my interest in the subject has grown.

The study set about to analyze which factors matter most in whether a person is successful (by various measures), healthy, happy, and regards his life as well lived when he looks back in the later years of life.

The project was called the Grant Study, named after it's sponsor, W.T. Grant, the founder of a department store chain. For 72 years, the study at Harvard tracked the lives of 268 men who entered college in the late 1930s.

The study was meant to be longitudinal (over a long period of time) and exhaustive. Researchers assembled a team of psychologists, psychiatrists, social workers, medical doctors, physiologists, and anthropologists.

In 1967, Dr. George Vaillant, a Harvard medical school professor assumed the lead role on the project and dedicated his career to it. Remarkably, he stayed with the study until it ended this past year.

The subjects were monitored, interviewed, and studied in many ways. Their personalities, aptitudes, physical and mental health, eating and drinking habits, exercise, career changes, and financial positions were all evaluated and tracked.

Vaillant drew a number of broad conclusions from the study and discussed those in depth in his book, Adaptation to Life. As the name might suggest, social skills, coping skills, and adaptation to change were identified as some of the most significant factors amongst a multitude that were analyzed.

However, in a 2008 interview, Vaillant was asked: "What have you learned from the Grant Study men?" And in his answer, he revealed his most important finding.

His response was: "The only thing that really matters in life are your relationships to other people."

I think this conclusion is significant in life, in business - and in projects as well. Now, I would not say that the only thing that matters in managing a project are your relationships. Because the success of a project is clearly determined by whether the project achieved its business goals.

Note that I did not say that a project is successful if it is on "time, on budget, and on specification." No, a project can claim to be all of those things yet still fail to achieve the actual, underlying business goals.

But the likelihood that a project manager will lead a project successfully to meet it's goals, in my opinion, does indeed correlate to his or her relationships with the people in the project. The project manager's relationships with the customer or business sponsor and with the project team are especially critical to the success of the project. But relationships with all stakeholders, and with senior management who are watching the project from the "outside", matter as well.

Relationship management is an important part of project management. Pay attention to and work on your relationships in every project. Remember, the project team is not a collection of interchangeable "resources", as some would have you believe. (You know that instinctively, of course. But be sure to remind those people up the ladder why you want to approve the members on your project team.) Every individual is unique, and you will be most successful if you understand each team member, including their strengths, weaknesses, and motivations.

Likewise, the customer or project sponsor is especially important to the project. Pay attention to and work on that relationship with care and a strong attitude of customer service. Understand their interpretation of the business goal and their expectations of the project. Work to understand their needs, their issues and concerns, and their communication style so that you can be not merely effective, but excellent in interacting with them throughout the project and having them as a satisfied customer when it is done.

Posch is the publisher of Project Success Tips. See Posch's bio on the Meet the Experts page.

Filed under Customer Relationship Mgmt, Teamwork & Team Building

Keeping up: New Ways of Working
By Elizabeth Harrin

Today’s economy and business culture is not the same as the one that most of our project management tools were designed for. The business world has moved on, and some parts of your organisation have probably moved on more than others. It’s likely that your project management function hasn’t moved on at all, and you are still doing the same old stuff you did 10 years ago. If it hasn’t broken, then why fix it?

I believe that as project managers we should make it easy for other people to work on our projects, and that means working in the same way that they do – both at work and at home.

Here are some new ways of working:

Podcasts

• When I started working in healthcare I downloaded everything I could about the industry to my iPod and learned on my way to work.
• Could be used for training courses and other project communication

Wikis

• Useful for long-term projects where staff turnover is high
• Encourages knowledge dissemination and discourages knowledge silos
• Customisable, searchable and better than email folders

Blogs

• Useful for project teams that are not co-located, so they can keep up to date with each other
• More useful for stakeholder communication and engagement, if you allow comments, especially when the stakeholders are external

Webinars

• Another training tool
• Useful for keeping project costs down when the training overhead involves travel
• Can be stored/recorded so if people can’t make the session they can catch up later
• I have also used this for collaborating on documents in real time with colleagues in another country

Messaging

• Workplace use of messaging tools like MSN have yet to catch on widely, but the potential for being able to see when your colleagues are online and available to talk is great
• Employers need to get over the fact that we would chat all day about non-work things before this takes off, but people are used to using the technology at home

SaaS

• “Professional” project managers aren’t worried about this at all, but some of the tools out there mean they should be. SaaS has the potential to make everyone a project manager
• Very useful for small-to-medium projects
• Some tools manage status updates by email, removing the need to be any good at scheduling
• If these tools are in use in your organisation amongst people who don’t have ‘project manager’ in their job title, then how do you engage them when they are stakeholders in your project? They will have certain expectations of project management tools and you need to be sensitive to this.

Plus collaboration tools like Microsoft Sharepoint, the need for real-time reporting which other departments probably have and the need to engage with and provide information for mobile users. You can’t open my monthly steering group report on a BlackBerry, and that’s a bad thing.

I’m not saying you should go out and adopt all of these in your project now. That wouldn’t be practical, and probably isn’t right for the culture of your team or your organisation. However, if there are things on the list above that you haven’t considered for your project, you need to understand why you aren’t using them. They all tools for your project management toolbox. As with any project management framework, you don’t have to use everything, just pick and choose what works for you and understand why you are leaving the other bits to one side.

At the APM conference last month I asked the audience if their project management style reflected the way others work in their organisation. The results were exactly even: 50% agreed, 50% disagreed. So while some of us are making progress with working in the way others work, there is still a long way to go. Next week I’ll be looking at the progress we have already made towards closing the gap.

Elizabeth Harrin, BA, MA, MBCS, is the author of the book "Project Management in the Real World", writes the irreverent blog A Girl's Guide to Project Management, and is a columnist for pmtips.net. (This article was previously published on her blog at this page.) See Elizabeth's complete bio on the Meet the Experts page.

Filed under Project Management Tools

You’re a PMP, but Are You a Project Management Professional?
By Lee Lambert, PMP

In the last several years I have had the opportunity to speak to over 8,000 Project Management Professionals (PMPs) in many of the largest PMI membership chapters in North America. During those sessions I conducted non-scientific polls to determine the depth and breadth of the application of the Global Standard, A Guide to the Project Management Body of Knowledge (PMBOK) to which this group of dedicated professionals had been tested to earn this prestigious certification and take their place among the elite in their chosen field.

Granted, 8,000 is a small sample from the over 350,000 PMPs worldwide, but frankly, I was shocked with the results of my simple survey and what the implications were. Fundamentally, I sought two pieces of input: 1) how many of the PMPs were consistently utilizing the Work Breakdown Structure (WBS) as described and illustrated in The PMBOK on their projects and; 2) how many were implementing the Precedence Diagramming Method (PDM) using the WBS Work Packages to determine logic relationships/work flow based on work content and resource allocation decisions.

When asked to simply raise their hand if their response to my verbal query was affirmative, the data distribution among the 8,000 plus respondents was as follows:

WBS--a total of approximately 1,500 (less than 20%) PMPs raised their hands

PDM--a total of approximately 900 (less than 12%) PMPs raised their hands

Interpretation: As a profession, project management may have a problem! We have far too many individuals who have worked hard, attended the best project management training and invested time and money in earning their PMP credential, but now are admittedly not adhering to the very same standards to which they were tested and for which they should be held accountable.

The reason I chose the WBS and PDM as the basis for my study was that these two fundamental concepts are at the heart of successful project management. Without proper and dedicated attention to developing these two “products” from the myriad tools and techniques available to today’s project management professional in planning and executing a project, the reality is the rest may well be “smoke and mirrors”.

First, let’s examine the potential of the proper use of the WBS.

Most PMPs would admit that one of the biggest challenges facing them in successfully delivering the traditional triple constraint is the lack of clarity of scope definition and/or requirements definition. The careful use of the WBS concept will reduce or eliminate this problem by providing the framework to decompose the work/deliverables to a size that significantly enhances the clarity and articulation of expectations among all involved parties—thus creating the basis for one of the most important components of PM—measurement of status/accomplishment over time. The smaller the work package, the more precisely status can be measured based upon objective indicator milestones with designated completion criteria.

Additionally, the more clarity in the work content/requirements the more effectively “skill set match” can be achieved when assigning human resources, allowing the impacts of skill set mismatch caused by resource capability/availability constraints to be evaluated and the impact on the project’s timing and cost can be calculated using:

Duration Impact = Effort/Productivity divided by Resource Availability

Cost Impact = Effort/Productivity X Resource Rate

The benefits of the well developed WBS are not limited to an individual project. The Enterprise Project benefits become obvious as individual project data can be “merged” to facilitate project prioritization based on resource capacity and work load conditions which can be quickly assessed and vital decisions made as to resource assignments based on mission critical projects criteria. Add to all of these advantages of the effective implementation of the WBS concept the significantly improved ability to identify and manage change as it occurs on the project and you can begin to see why the WBS is at the heart of productive use of the project management process.

Now, let’s examine the benefits associated with the appropriate use of the PDM concept.

The only way to reliably determine the duration of any project is to develop a realistic work flow built upon the WBS work package output. The PDM allows the project manager to articulate the output-input relationships of all work content. Once the basic “logic” of the work flow is established, estimated durations are assigned to each work package (based on the resources assigned or the best resource assignment assumptions) thus enabling a forward pass/backward pass to be completed. PDM is NOT a Bar Chart. Bar Charts are created as an output of a well developed PDM!

Once the “foundational” logic network is created, the ability to optimize work flow relationships and assess impacts of resource “bait and switch” decisions, modification of logic relationships-- such as overlapping or fast-tracking is obvious. Additionally, the impacts of the work package’s actual status as the project evolves can be input and a meaningful “cause and effect” analysis can be accomplished to determine the need for further optimization or corrective action to assure the project’s schedule remains achievable. These actions include decisions regarding the determination of float utilization and the assessment of the potential for any given float path becoming a NEW critical path.

Add to these benefits, the Enterprise advantage of being able to significantly improve the ability to manage a fixed resource base in a multi-project, shared-resource and or constrained resource environment that results from the “merging” of individual project PDM information into an Enterprise-wide resource utilization data base.

Using the WBS and PDM tools of our trade is NOT an option! If we are to provide the perceived (expected) benefits associated with the earning of the PMP designation, then we must practice what we preach. We must become proactive in proving the value of using the tools of the trade—not just talking about them.

PMPs must lead the way in transforming great training into even greater action on their projects. The PMP must make a concerted effort to educate up the organization to assure the critical decision makers are aware of the substantial benefits to be realized from using the fundamental tools of the profession—the WBS and PDM.

Lee Lambert is CEO of Lambert Consulting Group, PMI Fellow, PMI Distinguished Contributor, and PMI Professional Development Provider of the Year. See Lee's full bio on the Meet the Experts page. You can reach him at Lee@LambertConsultingGroup.com or at www.LambertConsultingGroup.com.

Filed under Project Management Techniques

Issue 4 - November 8, 2009

In this issue:

• Sarah Gilbert is a new contributor to the newsletter. I imagine many of you will easily relate to her article. So stop and think about her message!
• Hal Macomber summarizes his rules for project managers from the lean perspective. This is a great set of PM principles and worth studying often.
• Ray Posch writes about the magic that happens when a project team is both empowered and committed. It's the "empowered" part that can be hard in many organizations.

Too Busy to Think

By Sarah Gilbert

Overloaded managers run the risk of making bad decisions and alienating themselves from important information

Everyone has had a conversation with someone who clearly wasn’t listening. You know the signs. Maybe their eyes keep drifting toward their computer monitor or they keep making faces at people in the hall. This person probably thinks they are multi-tasking, a favorite pastime of the overbooked, but mostly they are just absorbing less information and being rude at the same time.

Running from one meeting to the next or spending lots of time responding to e-mail and voicemail actually can be a recipe for becoming more out of touch. It seems like a paradox, but using all this new technology to stay in touch, might be sending the wrong message to people who really need to speak with you. And it’s probably not giving you much time to really process the information, either.

Consider this scenario: A project manager got a funny sense yesterday that there was really something wrong with the data center. (Smoke was coming from a few of the servers, but not a lot of smoke.) But the project manager doesn’t want to alarm you, and isn’t sure whether or not smoke should be coming from the data center, so she sent you an e-mail. You didn’t respond. She thought that you lack of response meant that smoke in the data center wasn’t a big deal, so she decided to wait to see what would happen.

The next day there was even more smoke coming from the data center. Now, she was more worried. Maybe you didn’t get her e-mail, so she decided to stop by your office. You’re there, but running off to a meeting. You give her all the signs that you’re doing something that is a very high priority (lack of eye contact, shuffling things around on your desk, grabbing a cell phone, ignoring a ringing desk phone). She starts to tell you about the smoke coming from the data cemter, but you are interupted by a call on your cell phone.

The next day the data center blows up. You, the multi-tasking manager, can’t believe that this is happening. You are so accessible. You have an open-door policy. You have e-mail, a cell phone, a work phone, a Blackberry and people like YOU! How could you not have known that the data center was in so much trouble?

Well………. In spite of what you think you are doing, you are out of touch. Rushing around being really busy might make you feel like you are doing more in less time, but you’re sending the wrong signals to key people who should be telling you important information. And don’t even try to blame them! (I know you’re thinking it.) Furthermore (and this is probably the bigger problem), all that rushing around isn’t giving you any time to think. Good communication takes concentrated, conservative effort.

A single, well-constructed set of e-mails, phone calls and meetings is much more effective at communicating a set of well-constructed ideas than 100 meetings, phone calls and e-mails to see “what people think,” “brainstorm” or “get some feedback.”

The reality is that we are often getting too much feedback. Without the time to stop and consider what it all means, we’re not really communicating at all. We’re just throwing words at each other. So, stop reading this article and stare at the wall for 15 minutes. You just might learn something.

Sarah Gilbert is a project management consultant and can be reached at
sarah.gilbert@what-if-project.com.

Ten New Rules for Project Managers
By Hal Macomber

10. Adopt practices for exploring a variety of perspectives.
    We think we see what we see, but we don't. We really see what we think. Remember the blind men and the elephant. Make it your habit to inquire what others see. You'll see more together.
     
9. Stay close to your customer.
   Clients' concerns evolve over the life of a project. Take advantage of that to over-deliver. Stay in a conversation with your client to adjust what you are doing.
    
8. Take care of your project team.
   We've come to accept that the customer comes first…the customer is always right. We can't take care of the customer if we first aren't taking care of our project team. It's a challenge. While there are some things we can do for the whole team, it comes down to taking care of each team member as the individual that he or she is. And to make it more difficult, then we must bring their various interests into coherence.
    
7. Keep your eye on the overall project promises.
   Project work can be difficult. It is easy to loose sight of what we are doing and why we are doing it. Remind your team and yourself of the overall promises and how you are doing fulfilling those promises.
    

6. Build relationships intentionally.
   Project teams come together as strangers. To do great work…innovation, learning, and collaboration…all take people who like and care for each other. Don't leave that to chance. Start your projects by building relationships among team members.

5. Tightly couple learning with action.
   Projects are wonderful opportunities to learn. Don't put that off for the after project lessons learned. Make it your habit to incorporate learning loops in all your project activities. Your team will appreciate it. Your customer will benefit from it. And best of all, it will make your job easier.
    
4. Coordinate meticulously.
   A project is an ever-evolving network of commitment. Keep that network activated by tending to the critical conversations. See that people are making clear requests, promises that have completion dates, and share opinions that advance the purposes of the project. Without attention to those critical conversations the project will drift.
    
3. Collaborate. Really collaborate.
   Make it your rule to plan with those people who will be the performers of the plan. Don't wait 'til the project has gone south to get their help. Start out that way. Continue collaborating as the usual way you work through the project.
    
2. Listen generously.
   People are able to say what they can in the moment. For the most part, people are well-intended. Give them the benefit of the doubt. Take the time to listen. Ask questions. Seek others' opinions. And while you're at it, don't be so harsh on yourself.
    
1. Embrace uncertainty.
   Expect the unexpected. There is far more that we don't know and can't know than what we can anticipate. Be resilient to what life throws at you. Anticipate that your team will learn something along the way that can and should change what you have promised and how you can deliver on your promises. And when you take a set-back — we all do sometime or another — review the other nine rules for how you can work your way out of it.

This has been previously published on Hal's blog, Reforming Project Management at www.reformingprojectmanagement.com. © Hal Macomber. See Hal's bio on the Meet the Experts page.

Building Empowered and Committed Teams

By Raymond Posch

In business, work is done by individuals or by teams – either functional teams or project teams. Organizing and building effective teams is a core competency of business management; and where projects are concerned, it is a core competency of successful project management as well. In my opinion, project managers understand this critical successful factor much more clearly than most other business managers because the team is so crucial to project success.

In this article, I want to look at high performing teams and the role of empowerment… Only a few times in my career have I been involved with truly empowered teams, and it is amazing what they can accomplish.

High performance teams – teams that perform at very high levels – almost always have three critical characteristics (among others):

• The team is empowered to accomplish the goals of the project; 
• The team is truly committed to accomplishing the goals of the project; and 
• The team is the right team with the right skills for the project. 

The problem in most cases, at least in my experience, is that the culture and values are not in place in the organization to support the reality of high performance teams. The organization may talk about empowerment, but does not make it so – usually because command and control structures or attitudes are still too embedded in the organization or the management team. Or the project manager or executives may ask for (or worse demand) commitment, but they do not enable team members to be fully committed to the business goals or the project at hand.

There are some companies that truly “get” empowerment, and that truly enable employees to get committed to a project by giving them what they need – which is clarity about the goals, lots of information and communication, and cohesiveness in direction.

DaVita, the largest dialysis service company in the US, is one of those companies. It has a unique culture that fosters teamwork, mission, values, and purpose, and it emphasizes those things by frequently teaching and reinforcing the DaVita way. As a result of this empowering culture, DaVita has gone from startup to Fortune 500 in less than nine years! I can only hope other organizations begin to see the wisdom in this approach and adopt it.

Teams that are seen and treated as a loose collection of skills will never be high performance. Teams that are seen and treated as unique but equal individuals, who are capable of contributing outstanding work and who are brought together to create unity and synergy around the common goals of a project, are much more likely to achieve a high level of performance.

What can a project manager or business manager do to improve team performance?

• Seek to build the right team with not only the right skill sets but also the right chemistry and team spirit. 
• Work with management to truly empower the team. Insist that the team not have to go up the ladder to get approval for everything. Every time the team has to go “up the ladder,” it slows the team down and creates frustration within the team. 
• Promote empowerment within the team – that means not being the bottleneck for every single decision. Lay out guidelines for issues and decisions that should be brought to the PM and those that shouldn’t. 
• Involve the team in the whole project process. Don’t go off and develop the “project plan” without them, but instead fully involve them in the planning process. They will benefit greatly in the process and add lots of value. They will point out dependencies and issues that you would miss. They will suggest solutions or approaches that you would never think of. And then, ask them to commit as individuals and a team to the plan they came up with. 

Now, the project manager must also be the coordinator and facilitator to keep the team and the project on track in the following ways:

• Focus, and help the team focus, on the most important things for that day and that week. 
• Remind the team often of the project goals and provide clarity about the goals. 
• Provide lots of information about the schedule, due dates, deliverables, dependencies, and other factors that, if missed, can negatively impact the project. 
• Enable the team to communicate directly with the customers or business sponsors. 
• Continuously promote teamwork and information sharing. 
• Empower everyone on the team to resolve issues and roadblocks. 
• Maintain the project organization, visibility to management, and consistency of direction. 

The company culture may be a barrier, but by the very seeking to build a project team that is both empowered and committed, the probability of project success will go up enormously.

Raymond Posch is the publisher of the Project Success Tips newsletter and is also a project manager for DaVita Inc.

Issue 5 - November 15, 2009

In this issue:

• I want to begin including more articles in the newsletter that contain real project stories, with the insights gained or lessons learned, as told by real project managers. The first article is a project customer story told by me, Ray Posch. 
• In the second article (provided by permission of Bill Stewart of PMLG), Kel Mauldin describes a discussion about scheduling with a stressed-out project manager. Kel gives some good advice about building the project schedule and using scheduling tools. 
• Bob Hartman has written a new article for the newsletter, based on real observations, about the difference between "doing agile" and "being agile." To project managers who may not be using an agile methodology, or may not even know what "agile" is all about, this article is about commitment to the principles behind the project methodology.

How Issues Management can Make a Huge Difference to the Customer
By Raymond Posch, PMP, CPM

Back in 2001, I was a project manager for a hosting company. The project managers primarily managed the projects of moving new customers with large web sites and associated web applications into a dedicated hosting environment. Each project involved architecting the hosted solution, acquiring and installing the hardware and software, migrating the customer's web sites, applications, and content, and bringing them to full production operation. The projects usually involved a large number of people, both on our side and on the customer's side.

In December of that year, I was asked to support a large existing customer who was already fully moved in, so it was actually more of an account management role. But I think the story and lesson is totally applicable to project management.

The situation was that the customer was unhappy and had informed us that they intended to move out in 2002. I had demonstrated some skill in managing "difficult" customers, and I think the intention was for me to manage the move-out project and "manage" the customer through the interim. I was not asked to try to change the customer's mind since they had already asked for and received permission to be let out of their contract.

But I took it upon myself to find out why the customer was unhappy. And I quickly found out that the customer had a number of customer support issues that had never been resolved, and therefore they had every right to be unhappy.

I set about to manage the customer's issues exactly the same as if they had come up during the implementation project. I asked the customer to identify and explain their issues, and I captured each issue in a spreadsheet. I discussed the issues with the customer to determine how they wanted or expected the issues to be resolved, and I then discussed the issues with our technical support teams to determine what steps we could take to resolve each one and who would take responsibility for each. Some actions were assigned to me, some were assigned to other managers, and some were assigned to technical specialists.

Every week we tracked the progress of the issues and related action items. One of the issues should have been addressed during the setup and customer move-in – setting up appropriate monitoring of the applications and websites – wasn't, at least to the satisfaction of the customer, and that became a mini-project that I managed. That was a case where the customer wanted more monitoring than was in our standard hosting package, and we gave them a cost quote which they agreed to pay.

But here's the key... every week the customer saw us taking agreed-to actions and step-by-step over weeks, and in the mini-project case, two months, we resolved all of their issues. Customers understand that problems can occur, and that they may want deliverables (or services) that were not in the original scope. But they want to see a responsiveness and an ability - and, yes, even a process - to resolve issues that are a concern to them. This is just as true during a project as it is for customer support.

Well, you may guess that the customer changed their mind and stayed with us. In fact they stayed until we discontinued the hosting business 3-4 years later after being acquired by a much larger company that did not want to be in that business. While they were there, I managed a variety of infrastructure upgrade and new application implementation projects for them, and they were a great and valued customer.

Lesson learned: Never discount the importance of issues management and the importance of doing it well. And remember to include issues raised by the customer and stakeholders as well as those identified by the core team.

Raymond Posch is publisher of the Project Success Tips newsletter. See Ray's bio on our Meet the Experts page.

Scheduling — Don't Get Stuck on Senseless
By Kel Slone Mauldin, PMP, CPM

Imposed end dates. Deadlines. Mandatory finish dates.

No matter where I am in the travels of my job, I hear these same things. It is a reality that the world of business is moving at an excruciatingly quick pace. In a rush to meet time-to-market pressures there are more demands placed upon project managers to meet the time constraints of the business. So, I suppose it isn’t a shock that project managers have been beaten over the head so many times with business deadlines that they might get ‘stuck on senseless’ (an adaptation of General Honore’s famous phrase from 2005) when it comes to scheduling their projects.

Let me explain. Not too long ago I was asked by a student to take a look at a schedule she had built for a new project. It was quickly apparent that she had placed date constraint conditions on practically every task in her scheduling tool. I pointed this out to her explaining that she should let the tool calculate dates based upon the factors of dependencies as well as resource utilization and duration estimates.

“But, I can’t do that," she argued. “I have been given a mandatory end date for this project, and I have to make sure I will make the date.”

Confused by her explanation, I replied,“What does the business’ mandatory end date have to do with your method for building a sound schedule?” She looked at me like I was crazy.

“Because, I have to make that date,” she replied as if the answer should be obvious to anyone. “I don’t have the luxury of building my schedule that way.”

“So, if you’re using your scheduling tool just to match the picture that your sponsor wants to see, how does that help you know if you are really going to be able to make that end date?” I asked.

“Because, my team has no choice; we have to make the end date.”

“And, how do you know that you can make that date?” I asked again.

“Because, I have to make that date,” she said to me. It was through gritted teeth, I might add.

It was at this point that the lightning bolt hit me and I realized that a project schedule in a software scheduling tool didn’t mean the same thing for all project managers. For me, it was a tool to help me understand whether or not the business deadlines could realistically be achieved. For her, a scheduling tool was used to create a picture of what her leadership wanted to see and nothing more.

Now, I know I’m a little judgmental at times, but it seems to me that if a person’s main purpose in using a scheduling tool is to create a picture instead of using it to evaluate the very real risk of whether the mandatory end date can be achieved – well, that’s just stuck on senseless. It’s the equivalent of my jumping out of a plane knowing that I must be alive when I hit the ground, but I have no parachute. I have no idea how I will arrive alive. I just know that it’s mandatory, so I will ‘find a way, somehow’.

It is true that projects must achieve the business’ time objectives, but that doesn’t mean then that suddenly proper project scheduling is thrown out of the window. How can the business assess whether or not to continue with a project if they don’t have realistic information with which to make a decision?

It is also true that management may not always like the news that a proper schedule would tell them. Especially if the schedule shows that their business deadline can’t be achieved. But, is this a reason for a project manager to decide to show management what they want to see through building a picture instead of a true schedule?

It’s a tough position to be in as project managers because though we always want to be the ‘can do’ people for our management, sometimes we are given constraints that are beyond real capabilities. But, the goal is to be a provider of accurate information to our management, not just someone who is good at creating a picture of what our management wants to see. Our role is to not always be liked. Our job is to sometimes deliver hard news. Our position is an uncomfortable one, at times. But, it’s necessary for the health of the business.

So, the next time you are given a hard end date, document it. Write it down. Then forget it momentarily as you build a realistic schedule the right way. If you do that, you will have your parachute. You will have information that you can take back to your management to recommend alternatives, if needed. And, you will have your integrity.

Your project and the business are depending upon your sensibility in proper planning. Don’t get stuck on senseless.

Kel Mauldin was a trainer and coach with Project Management Leadership Group when this article was  published in the PMLG newsletter. She is now a busy mom. But she can be reached at kelmauldin@gmail.com.

Doing Agile versus Being Agile
By Bob Hartman

I spent the past week in Orlando, Florida at the Agile Development Practices conference, and I heard a number of people say “We do agile at our company.” When pressed further it suddenly became “We do agile at our company except we don’t do …”

To me that sums up the problem of DOING agile versus BEING agile. It is quite easy to DO agile. You pick the non-threatening pieces and parts and simply do those. Then you say you are doing agile and no one is the wiser. Unfortunately, when pressed you have to admit to not quite doing agile very well.

Being agile is completely different. Being agile means you understand the principles which lead to true agile success. It also means the team and organization are both constantly improving.

When you are being agile, daily standup meetings and retrospectives are both very important meetings which help the team be successful. Finally, being agile means being unafraid of failure. Doing agile has none of these qualities because it is all about doing the agile practices, not living the agile principles!

How do you go from doing agile to being agile? You start by understanding the difference. To be fair, most agile teams do agile rather than being agile so keep in mind you are not failing – you probably just didn’t know something better is available.

Once you understand the difference you can start to rely on the process to self-correct you toward being agile. For example, during the next retrospective ask why the daily standup meeting is a boring status meeting instead of a vibrant exchange of information which helps the team toward success.

Perhaps you can ask why the team keeps making the same mistake of not meeting the commitment made during iteration planning (maybe you need to go back to real basics and ask why iteration planning isn’t a commitment at all). It may help to ask if the team is willing to be agile and work toward continuous improvement rather than continuous mediocrity.

Once the questions are asked the team should strive to find some action items which will help them get better in those areas. If the team is truly dedicated to BEING agile rather than DOING agile they will find action items which they can commit to in order to improve. This is the key first step to being agile. Once you have a breakthrough in this area it is very easy to continue being more agile each iteration.

A journey of a thousand miles begins with the first step. Is it in you and your team to take the first step to go down the path of BEING agile?

Bob Hartman is President of Agile for All, a company that provides consulting, training, and coaching on the agile project methodology. See Bob's bio on our Meet the Experts page. He can be reached at bob.hartman@agileforall.com.

Issue 6 - November 22, 2009

In this issue:

• Glen Alleman's continues his series on programmatic risk management with installment #2, and he gives us some "words of wisdom".
• "Do your clients seem crazy?"... That's the question asked by Sarah Gilbert in an article about the importance of understanding that the customer's context is different than yours.
• Elizabeth Harrin discusses what makes a good project sponsor. 

Programmatic Risk Management - Part 2
By Glen Alleman

The first article introduced the idea of “uncertainty” in cost, schedule, and technical performance of projects. This uncertainty is defined literally as the “lack of certainty.” This is a tautology of course, but important for understanding the concepts of programmatic risk.

The idea that uncertainty and the risk that it produces can be “programmed out” of the schedule or a cost model is a false hope. All schedules and their associated costs have uncertainties. Uncertainty is about the variability in the performance measures of the project. Uncertainty is about the ambiguity associated with a lack of clarity. Discovering the sources of this uncertainty or ambiguity is the beginning of a programmatic risk management process. In many cases uncertainty arises from the basic processes of the work. This is the Deming uncertainty. (http://webserver.lemoyne.edu/~wright/deming.htm) 

This is the “noise” associated with the normal operations of a project. Work never completes in exactly the planned amount of time in the exactly the planned sequence. Items cost “more or less” what was planned. This uncertainty is a natural statistical process built into the project work. 

Trying to manage away this uncertainty is likely a futile effort, a waste of time, and actually not possible. The Japanese call this “Muda” in the Lean context. It’s the noise in the system. Accept the noise, have a buffer for the noise, allow variances to occur. 

The first question is while managing in the presence of this natural variability is, “what are the limits to these variances that are acceptable for the project?” “What are the error bands on the variability for cost and schedule?” If the error bands are set too tight, the project management staff “chases their tail,” trying to keep cost and schedule within too tight limits. It is a waste of time and effort to try to control the naturally occurring variances in the plan. 

One approach sets the error bands wide enough to not trigger an exception report for these variances. This approach is “good enough” but what is missing is the knowledge of “how wide is wide enough?” for a specific set of tasks or during a specific phase of a project? What should we tolerate for the naturally occurring variances? What is the impact on the schedule of these variances? 

To understand the source of this natural variance, we need to understand – and accept – that project schedules and their associated costs are networks of random variables. The values of duration are not “point” numbers (scalars). They are “estimates” of the completion time drawn from a probability distribution of the underlying population of all completion times possible for the specific task. 

Next we need to understand there are two types of random variables: (1) static, which are part of the underlying processes of the project and are fixed; (2) dynamic which are evolving over time. These second type are called stochastic variances. These are driven by system time delays – someone is late, the echo of that late delivery impacts future in some random way. The interactions between all the elements in the project is not well understood, disruption in one area of the project impacts other areas.

The dynamic uncertainty is about the unknowns and possibly the unknowable. The static uncertainty in a program can be addressed directly in the plan with mitigation tasks. The dynamic uncertainty arises from the dynamic interactions between the tasks of the plan. This interaction and the outcomes to the end date cannot be modeled with static paradigms. What is needed is a tool that can deal with these types of variances. This is a Monte Carlo Simulation approach to modeling interactions and their impact on other elements of the plan.

The Process of Risk Management 

We’ll get to the concept of Monte Carlo Simulation in a few more editions. For now we still need to clarify a few details about variances and their impacts on cost and schedule. First let’s restate what programmatic risk management is all about.

Managing programmatic risk requires anticipation that identifies risks, also requires understanding of the source of risk, the impacts of these risks, and the interaction between the risks and the plan. A process is needed to guide the risk management activities. This process must address both the programmatic as well as technical risk.

In our next edition, we’ll learn about two standard processes to manage risk. One, the US Department of Defense Risk Management Framework. The other the, Software Engineering Institute Continuous Risk Management Process. Both are available for “free” from their respective sources. Both are supportive of each other and can be combined. Both are applied daily on high risk, high reward programs – like flying to the International Space Station, building the Joint Strike Fighter, and even deploying large IT systems.

So let’s leave with the first of many “words of wisdom”...

Risk Management is How Adults Manage Projects

This article is the second of a series by Glen on risk management. See Glen's bio on the Meet the Experts page. He can be reached at Lewis & Fowler or at his blog, Herding Cats.

Do your clients seem crazy?
By Sarah Gilbert

Seemingly erratic behavior by customers or managers cannot be understood without considering their beliefs and circumstances.

I had worked in technology consulting for less than a year when I started to realize that all of our clients were “crazy.” At least that’s what most of my co-workers thought, and I was starting to agree with them.

For a while, I wondered if it was us. Was there something special that our company offered that seemed to attract the biggest loons? So, I changed jobs to work with different clients and different co-workers. But those clients were crazy, too. (Even crazier, actually.)

By that time, I had a large enough sample size that I needed to start re-thinking my hypothesis. It wasn’t statistically possible that everyone in our organization was sane while everyone in their organization was nuts. This re-considering also happend to coincide with moving to a more senior position within my new company.

In spite of what my former peers might have thought, I hadn’t joined the dark side or become a bubblehead after sticking an upper management title on my business card. I had simply acquired more context, because I had more access to the beliefs and constraints that were driving the clients’ decisions. And although I was able to confirm that a few of them were really, truly nuts, most of them weren’t.

Instead of wondering why we were suddenly trashing a component of a product that seemed to be central to its appeal in the middle of the project (leading me to conclude once again, that the client was crazy), I saw it as a rational decision made under budget or competitor duress. I also started to get the sense that the client might think we were crazy, too. Maybe we were.

I have since come to the conclusion that most people are almost always acting rationally IF (and that’s a really big “if”), you take into consideration both their circumstances and their beliefs. And that is where the rub is. Most people don’t go around spouting what their beliefs are. In fact, some people aren’t always aware of what their beliefs are. Further complicating the issue is that most of us also assume that our beliefs are the same as others.

Let’s say, for example, that I’m a manager and I believe that technology is the same as magic. So, as your boss, I would like you to invent a perpetual motion machine. You, the proud owner of an undergraduate degree in physics, explain to me that it will not be possible. Because, according to important laws of the universe, eventually our machine would come to a grinding halt.

“But why?” I ask.

“Because of laws that have to do with friction and thermodynamics,” you say.

“I think those are just excuses,” I say.

This could go on forever, until, ideally one day you uncover the fact that I believe in magic, and I actually believe that you are really a magician, even though your job title says technical developer. Making this discovery is unlikely to make you change my belief, but at least now you have a better understanding of my point-of-view. This is crucial to your communication with me (and my communication with you, incidentally).

So, next time, you think someone is just crazy, poke around and try to find out why they might be acting that way. Consider who they are and what circumstances they’re in. If you can get outside your own crazy ideas, they might just seem a little more sane after all.

Sarah Gilbert is a project management consultant and can be reached at
sarah.gilbert@what-if-project.com.

What makes a good project sponsor?
By Elizabeth Harrin

Having a good, active project sponsor is one of the ways you can ward off project failure. So if you are in the enviable situation of being able to choose who you have as your project sponsor, you need to look for someone who will do a good job. And what sort of person is that, then?

Well, a sponsor is the project’s figurehead, someone who represents the project team at board meetings, who looks out for the project’s interests, who can provide strategic direction and most importantly, wants whatever it is the project is going to achieve. Every project should have a sponsor. Ideally, they should be someone who is going to have to live with the results of the project for long after the project manager has moved on. A sponsor who is not implicated in the delivery will find it hard to be motivated by the project and may be unable to take decisions about something that is outside their sphere of influence.

Eddie Obeng in his book Perfect Projects defines the sponsor ‘as a person who:

• invented the idea and really wants to do it
• controls the money
• wants the end product or will end up living with it
• can provide effective high-level representation, and smooth out the political battles before you get to them
• ‘owns’ the resources
• acts as an effective sounding board/mentor.’

The last point here is particularly relevant, and often missing. Sponsors who are unavailable to their project manager cause problems because this delays decision making. On a practical level, the ‘absentee sponsor’ will not be able to provide the strategic vision and answers the project team need to do their jobs. On a people management level, projects with poor sponsors suffer from low morale and all the relative impacts this has on their work. After all, if the sponsor isn’t interested in what they are doing, why are they bothering?

Good sponsors understand what their role on the project team needs to be. They won’t turn up to every meeting but they’ll occasionally send out a thank you email to everyone. They will be available when the project manager needs to escalate the information and they will pass down information that is relevant to the project too.

Generally, the more experienced the sponsor, the easier this relationship will be for the project manager although anyone can be a good sponsor if they have enough authority and work alongside the team, asking ‘what do you need from me?’

And having a project manager brave enough to answer the question honestly helps things along too.

Elizabeth Harrin, BA, MA, MBCS, is the author of the book "Project Management in the Real World", writes the irreverent blog A Girl's Guide to Project Management, and is a columnist for pmtips.net. (This article was previously published on her blog.) See Elizabeth's complete bio on the Meet the Experts page.

Issue 7 - November 29, 2009

In this issue:

• How can you tell if you're doing a good job as project manager? Sarah Gilbert suggests some quick and simple ways to do just that. I think her assessment is quite good.
• Bob Hartman recommends keeping agile simple. He describes the "6 principles of simple agile." 
• Ray Posch takes a shot at describing the top 5 skills of project managers.

The starting point is the six basic principles of what I call “Simple Agile.” Here are the six principles:

6 Principles of Simple Agile

Let’s take them one at a time, but very quickly. (I’ll probably write more about each of these in a future blog entry.)

1. Collaborate

Very simply, “collaborate” to me means to communicate effectively with each other. There is no place on an agile team for a lack of communication. Communication needs to be as near to real-time as possible, and hopefully as high bandwidth as possible. In rare cases people on the team may not choose to use the best communication method available, but that should be the exception not the rule.

2. Work together

If we communicate well then we need to follow it up by working together. For example, a Product Owner, tester and developer have all agreed on what a specific story means. This does not imply the tester and developer go off their separate ways. Work closely together to make sure the shared understanding stays shared. I’m not sure what to call this other than “pairing.” I’m also in favor of pair programming for a lot of reasons. It has been proven pair programming signficantly increases product quality without affecting productivity.

3. Honor priorities

Always, always, always work from a RANKED product backlog. You must work on things in the order they appear in the backlog unless there are exceptional circumstances (like a story is too big to fit in the iteration so it is deferred until the next iteration in favor of a smaller story now). Everyone should follow the rule “the next thing you do should be a task in the highest priority story you can work on.” This implies more than one person will work on a story (swarming). It should also mean teams have fewer open stories (limiting work-in-progress). This will lead to delivering the maximum value every iteration.

4. Respect the customer, the process, the product, the team and each other

When does a customer know exactly what they want? When they see it of course! When do they know how they feel about your product? When they see it. Let them see it more often, gather feedback and utilize the feedback. Respect the process by sticking to it and holding each other accountable for process success. Respect the product by reducing complexity and technical debt. Respect the team by not having unrealistic goals, being sustainable and letting them solve their own problems. Respect each other by working together toward success and supporting each other at all times. I could go on and on with this topic (it is a personal pet peeve), but I won’t. If you get a chance, do the following exercise: On a piece of paper write down all the different ways respect of these things could be improved, and next to each write down a list of the downstream effects such a change would have. You’ll be amazed how much difference this can make toward success.

5. Do the simplest thing that works – then stop

Everyone in the product development industry has a tendency to do too much with every feature. We even have a name for it: goldplating. It is very easy to fall into doing it. Ever hear something like “While I was in the area I did XYZ.” or how about “The story didn’t say to do this, but I knew the user would want it so I did it.” Both statements should never be heard on agile teams. We should do the simplest thing that works – then stop. Ask the customer (remember we are respecting them by getting them involved) if we hit the mark.

6. Improve every iteration

Remember, 1% better every 2-week iteration will make a team more than 25% better after a year. Big improvements aren’t needed, just a lot of small ones. This might be the most key principle of “Simple Agile” because it enables us to understand we will never be perfect. Keep trying to get better and you will.

These 6 principles are designed to get teams back to thinking of what is important. They draw heavily from the principles of lean software development. In many ways they could be considered rewordings of those principles. I believe in these principles. I believe they make a huge difference when teams believe in them as well. How many are you violating and what are you going to do to get back to doing the basics?

Bob Hartman is President of Agile for All, a company that provides consulting, training, and coaching on the agile project methodology. See Bob's bio on our Meet the Experts page. He can be reached at bob.hartman@agileforall.com.

The 5 Top Skills of Good Project Managers
By Raymond Posch

I've worked with and managed project managers over many years. Based on my own observations of what I did or did not do well on my projects, and similar observations about other project managers on their projects, I offer my assessment of the top 5 skills of good project managers:

1. Attention to Achieving the Project Goals – In many types of projects, especially technology projects, it can be easy to get wrapped up in the details and the technology and lose sight of the business goals. The focus of the team and the project shifts to a technology goal – for example, build an XYZ system, instead of focusing on solving the business problem.
   
   The project manager and the team need to clearly understand the business goals before detailed planning and work starts on the project. Then, the project manager needs to remind them regularly about the goals and how the project work relates to those goals.
   
   
2. Attention to Details – Probably the most-cited skill for project managers is attention to detail, and rightfully so. Projects of any size have hundreds and thousands of little details that must be attended to at the right time and in the right way throughout the course of the project. That’s why senior managers should not manage projects… They are supposed to deal with the big picture, not the details.
   
   It’s not the job of the project manager to handle every detail, but it is the project manager’s job to remind the team or ask the team about the details of the tasks they are doing.
   
   
3. Communication and Coordination with the Team – The planning and execution of the project is done in the day-by-day, week-by-week grunt work of the project. And it’s done by the project manager working directly with the team to make it all happen… communicating and coordinating about their activities, the dependencies between the activities, the amounts of time to get the activities done, the issues that must be resolved, and so on.
   
   Daily communication and coordination is the core of managing the project. It requires good organization and good people and verbal communication skills.
   
   
4. Problem Solving and Communication outside the Team – General problem solving is an important project manager skill because problems and roadblocks must be dealt with frequently. In most business projects, it usually means finding the persons outside of the team who the project manager or team must work with and taking the appropriate steps to get the problem resolved. It may mean going up the management ladder to escalate the problem and get the necessary attention, prioritization, and resources directed toward the problem to get it resolved.
   
   This particular skill set also involves communicating regular status to management about the progress of the project and issues that might be impacting work results, schedule, budget, etc. It requires excellent people and verbal communication skills and good written communication skills as well.
   
   
5. Customer Relationship Management – In business projects, it is important that the project manager maintain a good working relationship with the customer, whether the customer is external or internal. Managing the customer’s expectations is a key part of this – not in a manipulative way, but in an honest and relatively open way. The customer needs to know what is realistic in developing the product and what is not, and customers always like to be kept informed about how the project is going and whether you, as the project manager, are responding to issues in the most effective way.
   
   Managing the customer relationship also involves communication with management – keeping them informed about project issues, whether the customer is happy and quiet or unhappy and likely to escalate. Like several others, this area of performance obviously requires good people and communication skills too, as well as good issues management – which is all about tracking customer issues and managing them to the satisfaction of the customer. 
   
   Relationship management generally is important - building and managing relationships with the core project team, all stakeholders, resource managers, and so on - and requires project manager time and attention. But the relationship with the customer (or business sponsor) is critically important.

Note that the above top 5 skills are pretty much equal in importance. I have not listed them in priority order. Project managers need all of these in order to succeed.

Additionally, there are many more skills that a project manager must have, but if he or she does these five well, their probability of success with most projects will be high.

Raymond Posch is publisher of Weekly PM Insights newsletter. See Ray's bio on our Meet the Experts page. He can be reached at ray@projectsuccesstips.com.