Why doesn’t anyone listen to the customer?

February 27, 2009 — Bruce McGraw

The tired cliché about the customer always being right does not always sit well with IT professionals, software developers, or even project managers. In private meetings, I have heard many contentious thoughts expressed:

“The customer does not know what he wants.”

“The customer does not understand what he’s asking.”

“The client is stupid.”

“This client is a flake.”

Wow! What’s going on here? Part of the explanation for this “failure to communicate” probably stems from the way that requirements are often generated – especially in projects. The customer begins with a problem, a need, or an itch to be scratched by a new software solution. He presents his challenge to—usually— marketing or business development professionals who assure him that XYZ Company can make his pain go away.

I can’t help but think of the classic picture of the “Tire Swing Cartoon” that depicts the mis-communication of requirements.  How the initial requirements are created depends on who is in the room while dream and reality crash together. In all likelihood, the company bidding for the project will include project management staff in putting their bid together to provide creativity and a dose of reality—although this is often done under the duress of a fixed cost and delivery schedule.

Eventually agreement is reached on basic deliverables, schedule, and cost among these parties (with emphasis on the soon forgotten “basic” word). In the pleasure of the moment, future problems are expected to be resolved through requirements management by the PM.

The customer’s role is not over when the contract is signed, however. Most good projects call for concept demonstrations, prototypes, and beta-test versions of the software before the customer accepts delivery and the contract terms are fulfilled. It is in these feedback sessions between the users and the developers that frustrations may manifest and charges fly: why doesn’t anyone listen to the customer?

Now, don’t get me wrong, I believe the stepped process in developing, refining, and final acceptance is an essential best practice in creating software for good project management. But as the proposed solution begins to emerge and be displayed, it is typical that users will want more and want it differently. Because users are not coders or system architects, they will express their desires in ways that do not appreciate the level of effort required or the implications of what they are asking. Nor do they understand the effect on cost and schedule to comply with their requests.  Even with new software methods like Agile development, a customer is not going to understand software problems any better than they do in a traditionl project management methodology.

That’s the PM’s job. It is also the PM’s opportunity to work with the users to better understand their needs and to explain in non-technical terms how the user can get what he wants, what the changes and additions will cost, and how they impact the schedule, cost, and quality/scope (see the Project Triangle)

“Good project managers recognize that every decision has opportunity costs. If you decide to add more features, quality must drop, or the schedule must slip. If you decide to cut the schedule, features must be drop or quality must drop. There is no way around the natural tradeoffs of resources, time and quality.”  - Scott Berkun in The List of Reasons Ease of Use Doesn’t Happen (November 2002)

The PM must also be adept at translating the user’s world to the developers. He or she must listen to the customer and try to discern what is really meant by, “can I download this on-line data to a database on my notebook?”

One effective technique to gain a handle on real customer requirements is to create a “Concept of Operations” or use- scenario before a line of code is written. This user-centric step helps the customer understand what they will be getting and provides feedback to developers when the cost of change is much lower – as opposed to later in the development process. You can read Karen’s paper on “The Performance-Centered Design & Development Methodology” for more information.  Company XYZ may also find that it is very helpful in this early part of the process to call in an outside professional to facilitate the dialogue between the end-users and the developer and PM staff.

If you have any tricks or techniques that facilitate listening to the customer, please share them via your comments.  Everyone benefits from sharing good ideas.

 

Posted in General Project Management, pm, Requirements. Tags: , , , , , , , . 1 Comment »

Do you need a PMO (Project Management Office)?

February 20, 2009 — Bruce McGraw

I am often asked by CEOs and senior managers, “Does our organization need a PMO?” Like all yes/no questions about complex topics that involve a cost– benefit trade, the answer to this question is, “It depends.”  Let me elaborate…..

What is a PMO?
Software development projects, especially complex ones, have a notoriously high failure rate—some estimates are as high as 60%–70% of software projects fail to deliver on their requirements and cost estimates.

A PMO, often reporting directly to the CIO, provides guidance and support to projects in implementing best practices, complying with standards and using tools to help keep projects on track. PMOs may conduct project reviews and increasingly are being expected to be directly accountable for project results. In some organizations, the PMO is staffed with experienced personnel who are loaned out to manage IT projects.

T.D. Jainendrukumar writing in PM World Today (January 2008) provides an overview of the duties of a PMO. He sees the PMO as responsible for: Practice Management, Infrastructure management, Resource Integration Management, Technical Support Management, and Business Alignment and his article describes these functions in detail.

What are the benefits of a PMO?
In an article by Megan Santosus for CIO, titled Why You Need a Project Management Office (PMO), she reported that her research found that more than 50% of those organizations with a PMO claimed improved project success rates.

At Cognitive Technologies, we encourage establishing an organizational PMO when projects are of strategic importance to the company’s future or projects are to be executed over multiple years, multiple business units or in coordination with outside organizations. We have found that a PMO helps organizations execute complex software development projects by providing increased:

  • Control
  • Collaboration
  • Communication

If you want to dig deeper, check out Cognitive Technologies white paper about our experience and recommendations regarding PMOs: “Why do you need a PMO”. 

Does your organization need a PMO?
Here are 5 yes/no questions that will help your organization decide if a PMO will help you do a better job managing your software development projects:

  • Is the level of complexity within the organization’s environment high—i.e., the effort may involve multiple departments (each of which has different stakeholders) within the client organization?
  • Is the project for an outside client who is likely to assign an Independent Validation (IV&V) consultant or auditor to the program?
  • Are specialized requirements involved? (For example, HIPPA information security requirements, financial security requirements, EV reporting, CMMI compliant process or execution levels, PMI best practices, or specialized time reporting and charge codes.)
  • Will a single methodology be enforced across the different projects or program team, requiring cultural and behavior changes for the individual contributors?
  • Will there be a large number of staff/people to be managed, assigned, and tracked (i.e., 100-150) across the projects or program?

One other good source for PMO thoughts is the 2003 article in CIO magazine on Why do you need a Project Management Office.

If you have worked with a PMO in your organization, please leave a comment and share your observations. In a near-future post, I will talk about the Do’s and Dont’s of setting up a PMO.

 

Posted in Best Practice, General Project Management, Leadership, project management office, Strategy. Tags: , , , . 9 Comments »

Why your project needs a predictive project schedule

February 13, 2009 — Bruce McGraw

Have you ever been frustrated because you were sitting in a status meeting and the project schedule indicated you would be finished yesterday?!  Whatever happened to “truth in scheduling”?  A predictive schedule is one of the most powerful tools a project manager has. It provides essential information on status, flags conflicts before they happen, and provides backup when requesting resources.

Believing this, I am frequently baffled at the reluctance of some PMs to create or maintain a project schedule.  I remember years ago in the research lab hearing a senior developer say, only somewhat tongue-in-cheek when requested to provide a schedule for his project, “If I knew how long it would take, it would not be research”.

Maybe what I have seen is the reaction of PMs being burned by schedules that were imposed from “above” or were regarded as meaningless paper exercises required to fulfill contractual obligations with no apparent conformance to reality.  Does this sound familiar to you? Whatever the reasons, some PMs choose to steer clear of real predictive scheduling.

For those who spurn developing a project schedule, I can assure you that you are missing a key ingredient in managing your project effectively. Project schedules are your friend—not your enemy.  And yes, I have heard the people who say I don’t have time for project management and schedules – it gets in the way of my real work.  I call those people “one man projects!”

Here are some of the reasons I believe predictive project schedules are important:

  • A project schedule requires that you identify tasks and their relationship to one another—this is important for risk management, staffing, and sequencing.
  • Project schedules provide the only picture of what has happened (actual) and what is now planned. (assuming they are accurately updated)
  • Project schedules help forecast resource requirements and provide a visual representation of task dependencies that will help you sell your needs to senior management.
  • A project schedule gives everyone on the team insight into where the project is going and how their efforts impact outcomes.
  • A project schedule helps you keep track of accomplishments, needs, and compliance with requirements.
  • A project schedule gives you an easy to use method to evaluate the impact of changes and requirements creep.

Several of my colleagues have similar thoughts and have shared them with me.  If you want to see their thoughts check out Don’s paper “How to Construct an Effective Project Schedule Using Microsoft Office Project” at http://www.cognitive-technologies.com/ or John’s presentation at http://pmchallenge.gsfc.nasa.gov/docs/2008/Presentation/John.Rigoli.pdf. 

I feel so strongly about the importance and utility of predictive schedules to project management, that in coming posts I plan to talk about: the characteristics of a good project schedule, getting schedule buy-in, building meaningful dependencies and constraints, identifying risks and accommodating them, how to monitor status, schedule-based reporting, and using tools to build, maintain, and share project schedule information.
So what do you think?  Feel free to reply or suggest topics of discussion for the BLOG.

Many of you have asked so – Here is John’s Video:

Posted in Best Practice, General Project Management, schedule, Tools. Tags: , , , . 6 Comments »

Keeping your project on track while the sky is falling (economically speaking)

February 5, 2009 — Bruce McGraw

Unless you have been underwater or on Mars for the last six months, you know that the economy in the United States (and globally) is in the worst shape anyone has experienced—except maybe your grandparents who talk about the Great Depression over Thanksgiving dinner. As a project manager, you are not immune from concerns about layoffs and falling investments and neither is your staff. In fact, you may find productivity steadily declining on your project as people’s individual worries trump their performance.

What’s happening?

Your staff is concerned about their job and the company’s future in this downturn. Layoffs are happening across industries, job types, and in all parts of the country. Many of them know good workers (and friends) who have lost their jobs through no fault of their own and they wonder, “Could I be next?” Their mental energy and focus is being distracted by thoughts of personal security: They may be in self-protect mode. This behavior is a primitive, old brain response to perceived threat and cannot be overcome with logical or rational thought.  And logic would be what I, and most project managers, would try to use.

What can the project manager do to help lessen fears?

First, acknowledge the fear. Listen to your staff in group meetings and individually. This may be hard as you watch the tasks and work not getting done, but try this step. This is not an hour long therapy session, just giving them tacit permission to express their fears. Let them know it is okay to be worried and to talk about it. The stages of grief are applicable here—shock, denial, awareness, acceptance, and integration. Talk with your staff about what can be controlled and what cannot. Be honest. If you have information about the company’s position and future plans, share it (to the extent that you can). Believe me, what your project staff imagines is happening is often (no—always) far worse than reality.

Next, increase the perception of control. Fear is about the unknown and loss of control. Tell your staff what you are doing to improve the position of your project, and therefore the staff, in the view of senior management. Encourage your staff to come up with cost saving ideas, schedule improvements, new business opportunities, and let them know how you are sharing that information up the organization’s management chain. Provide a role model of dealing with the uncertainty while still moving forward on project goals.

Finally, if reducing headcount on your project is unavoidable, make the process as fair and transparent as possible. Work with senior management to implement layoffs with humanity and respect for individuals. Those who remain will be aware of unfair or disrespectful treatment and it will color their perception of the company even after prospects improve. Remember the saying “There but by the Grace of God…. It could have been me.”

How can you keep your project on track?

Of course you still have the problem of keeping project on target.  When everyone’s performance is being scrutinized, it is essential that you have measureable project goals and a doable project timetable. If your original project plan was based on a six month deliverables, change the time frame and focus to quarterly or even monthly. You need to be able to report progress and production every time senior management asks for a new projection and report. In fact, you can do it before they ask for it!  This strategy also gives your staff more of a feeling of accomplishment than longer range timelines or project goals provide.

Pay more attention than usual to staff accomplishments and reinforce on-target task behavior. When a staff member is falling behind, offer to find help. Your creativity will be challenged many times in getting problems solved during this tough time, but you may be surprised at the willingness to help and the imaginative solutions your team, working together, can offer.

Listen to the grapevine. If rumors are spreading—and you can be sure they are— it is time for a reality check and accurate information. Share information good or bad—hoarding does not help. As a last thought, during your weekly project meetings, add an agenda item about the future of your project, your technology, and the company. Remind people that there is a future and that what is happening now, as bad as it might be, is not the final story.  You can set the tone and outlook by how you act and lead.

 

Posted in Best Practice, General Project Management. Tags: , , , . Leave a Comment »
Follow

Get every new post delivered to your Inbox.

Join 354 other followers