Project Management Institute

The birthday syndrome

the impact of a goal with no plan

Introduction

We have all heard of individuals who were suddenly depressed on their 30th birthday because they had expected to be millionaires, to own their own company, to be President, to be married, etc. These individuals are devastated because, at some point, they told themselves they would achieve their dream by the time they were 30 and, now, here they are.

The Birthday Syndrome event also befalls the 65-year-old, suddenly retired with a fixed income and nothing to do. They have nothing planned even though they've known for nearly 65 years this day was coming. One morning they wake up with no place to go, no money to spend, and nothing to look forward to but checkers in the park.

More devastating for the Project Manager is to find a requirement, necessary for successful completion of the project that has “fallen through the cracks.” Suddenly the Project Manager is put in the position of “crashing” to get a critical aspect of the project complete. The Project Team hasn't the slightest idea how it happened and they don't have time now to find out why.

This presentation discusses methods that should be incorporated by the Project Manager and Project Staff to define requirements in sufficient detail to fully discover significant items as they are presented throughout the project. This presentation will propose various techniques for defining the needs of the customer in terms of the project and not in terms of what the customer sees as significant at the time.

Lane Closed Ahead

The issue of failed milestones can frequently be traced back to some insignificant comment made by one of the customers in one of the meetings, in a hallway some time, or even before the start of the project. How does this happen? Missed requirements are the result of “The Birthday Syndrome”—the task is important enough to get depressed about now, but was somehow not important enough to get your attention at the time. Frequently the “depression” is actually a missed progress payment, removal from the project, or even dismissal from the company. More often than not, in this litigious society, the result is a lawsuit that can be devastating no matter what size firm is named as defendant.

The Birthday Syndrome is perhaps a close kin to the “One-Mile Syndrome.” We have all seen those drivers who stay in the right lane even when the signs clearly indicate the lane is closing. They're informed over and over again—“lane ends,” yet the driver is somehow surprised when they're at the end of the mile and must move into the flow of traffic. By the time they reach the end of the orange cones there's nobody in the left lane willing to let them in and they're stopped.

Perhaps the practice of riding the closed lane continues because there frequently is someone there to let them in? It could also be said that project goals might not be fully discovered because the Project Manager knows they have a project buffer for undiscovered issues. The Project Manager seemingly continues to ride in the closed lane because they feel they have enough of a buffer. The more buffer, the less reason to dig for the hidden issues—the “bombs.” The old phrase “a stitch in time saves nine” should be on every Project Manager's office wall.

The difference between the One-Mile Syndrome and the Birthday Syndrome is that the former happens even when there is sufficient warning. The Birthday Syndrome occurs when there is no warning of what's about to happen. There's an event that was unattended for a period of time during the project and the detail was not ignored, as in the case of the One-Mile Syndrome, but was unrecognized until the end.

Getting to the “Bomb” of Things

The Project Manager must be aware that events and requirements will be informally discussed over lunch, in a chance meeting in the hall, or before or after Project Planning meetings. Requirements buried in remarks or conversation may seem insignificant to the customer at the time, but later they become critical to successful completion of the project. Recognition of the importance of these issues won't be significant until the end of the project—the 30th birthday. A report was expected, a modified method of calculating was discussed, a move to a new operating system was joked about, or a testing requirement was written at the bottom of a very long email. No matter how the need for the requirement was delivered, it was not attended to properly or sufficiently.

The difference between a project in the red and one is the green is often a matter of perception. Many customers will define their needs in terms of their current position. Generally, they'll emphasize those areas immediate concern or events that have recently been highlighted as issues. The aspects of their jobs or their responsibilities that are more mundane, but no less important, are de-emphasized because they aren't currently issues or not currently being emphasized or measured by management. The amount of detail about the requirements for month-end-closing in an accounting application is dramatically increased in the week following closing than the detail obtained the week before month-end. The detail will increase even greater if the accounting staff is aware that they will be asked about month-end-closing as they go through the process.

One area of Project Management requiring highly defined skills on the part of the Project Manager and the members of the team, is the ability to consider even the mundane significant. To avoid the Birthday Syndrome it's important to recognize what will be important at the end of the project and not only what's important during the current project review meeting.

A successful interview process and effective listening skills are necessary to determine the who, what, where, when, why, and how of a requirements definition. It is necessary for the Project Team to listen to the customer, determine the needs, and fully understand who is going to use the product or service. The analyst must then move on to define exactly what is being done today and what is being requested. The timing aspects of the requirement and the conditions under which the requirement is truly a requirement will determine the when. Another important aspect of defining a requirement is the why. Why does the customer need the report to show the requested data? Why does it need to be secured? Why does the total need to be at the end of the report if it would be more useful at the top of the first page?

Finally, it must be determined exactly how the requirement is to be achieved and how it will benefit the customer. The “how” is the most important question. A poor understanding of how the goal is to be achieved can be devastating to a project. Even more important, however, is the definition of how the request will benefit the customer. Once the benefit is fully understood it options can be presented for how it will be achieved.

The interview or goal-setting meeting should be used to uncover the “bombs”—items that had not been considered as part of the project but are significant to the success of the project. The problem with most Project Planning Meetings is that they plan for what is already known or what has already been exposed. As Project Managers we frequently have our own expectations. These expectations act as filters that define what we hear the customer saying.

Anyone who has ever programmed knows the feeling of rushing through lines of code in your head as the customer is laying out their requirements for a change in the system. Very few of us can successfully multitask. Either attention is paid to the customer or it is paid to the changes necessary in the code. What percentage of goals missed on your last project resulted from not being attentive to the conversation?

For example, a goal of reducing Days Sales Outstanding would not appear on the project plan as a task. In order to achieve this goal, the entire project could simply be to produce a Days Sales Outstanding Report or it could be to provide training regarding methods of reducing Days Sales Outstanding. No matter what approach is taken to reducing Days Sales Outstanding; the analyst must understand how each task contributes to achieving the goal. This definition of the contribution must be stated in terms of the customer's perception rather than from the viewpoint of the Project Team member.

What a Difference a Decade Makes

For example, getting back to the 30th birthday issue, if the person turning 30 had been interviewed about their goals for their 30th birthday at the age of 20, they may have responded they'd like to be “comfortable.” The then 20-year-old may not have been thinking about being a millionaire, or moving up in the company, or being happily married with four kids, etc. They had a vague goal of being “comfortable” or “successful.”

A Guide to the Project Management Body of Knowledge – 2000 Edition presents a definition of a project as “a temporary endeavor undertaken to create a unique product or service.” If the result of a project is something unique, what is the possibility that anyone could have enough experience to fully define the requirements? In the same manner, the decade from age 20 to 30 is a unique experience. How could the person at 20 define exactly how they will reach a goal that seems so vague at that age? They have never been 30. How could they be expected to know what they need to achieve in order to meet even the vague goal of being “comfortable?”

We define expectations based on experience. The 20-year-old interviewee only knew what he had experienced and, consequently, only responded to what he were asked. At some point during the next 10 years of the “project” they further defined the word “comfortable” as “millionaire.” The depression comes because he never planned for this new definition. The same type of problem exists in Project Management when attempting to place milestones on a Project Plan. There are enough definitions of “complete” to fill a football stadium.

It hasn't been confirmed, but many people attribute Albert Einstein with having said something similar to: “One definition of insanity is doing the same thing over and over again and expecting different results.” This is especially true with Project Management issues and the interviewing techniques employed by the Project Team members. One method to avoid falling into the trap of missed specifications is to require that every Project Member, involved in the requirements definition aspects of a project, be required to finish every meeting with a detailed list of requirements they understood to have been expressed by the customer.

A “Letter of Understanding” should be part of every project meeting. This quick review should take no more than several minutes and requires only that the person responsible for calling the meeting also be responsible for documenting what happened. These summary notes are not meeting notes, but rather just a list of tasks that must be included in the project plan as a result of the meeting. It is a good idea to ask the participants to each keep their own list of items during the meeting, which they can compare to the list being presented. This simple process ensures that everyone in the meeting heard the items and no items were overlooked.

Of course, follow-up meeting notes should be distributed as quickly as possible after the meeting. These notes should contain the detail of what was discussed. One important part of meeting notes is that they should not contain any new material. If the meeting organizer finds that there are open questions, these questions will need to be evaluated in separate correspondence or in follow-up clarification meetings. There is nothing more confusing than presentation of the results of a meeting along with the presentation of a list of new items. Old items and new items are separate topics and should be treated as such when corresponding with the participants.

Just Because You're Paranoid Doesn't Mean They're Not After You

It isn't necessary to be paranoid or detailed to the nth degree. A definition of terms, as part of the project plan, could be sufficient to avoid the issue. There are numerous approaches that can be taken to support and educate Project Team members to improve their ability to interview the customer, and to better define requirements. For these techniques to be effective, however, they require an understanding that there are differences in background, experience, and goals that must be addressed at all times when dealing with the customer and other project team members.

How many times have Project Managers been misled by the customer's emphasis placed on tasks and milestones currently the subject of an audit, a management objective, or a customer complaint? This misplaced emphasis can create situations where the detail is attended to while the importance of the normal daily activity is minimized or, even worse, disregarded. The requirements for the norm may be mentioned as an aside, that the project should address some issue, but these details doesn't seem to be presented with the level of importance they will have when the “lane ends” at the end of the project.

The process of defining the basic requirements and then incorporating enhancements to the basic design requires the ability to define the needs of the customer based on normalized operations and then to consider the requirements for change or enhancement necessary to address the current priorities. The customer must be aware that the basis for every project is to “cause no harm” and then to provide improvement.

A thorough understanding of the requirements must be based on defined procedures, processes, and priorities relative to the current function. This current function must be fully understood before a change can be applied. It is necessary that the Project Team members be involved in as much of an effort to understand the current situation, as they are involved in defining new requirements.

For example, the design of a building is usually based on a requirement for the function that the building is to perform. A football stadium is designed to support all the functions associated with playing football. One obvious requirement is that the stadium must have locker room facilities for at least the number of players on each team. Yet, how does the Project Manager and the Project Staff recognize the importance of chairs in the locker room that will support at least a 350-pound lineman? It's these details that may not be recognized as important at the time and may even be an aside, but they are extremely critical when the lineman is sitting on a pile of twisted metal in the middle of the locker room floor.

I Would Do Anything…But I Won't Do That

As the football player sits in the middle of the floor it might be a good time to have a meeting to discuss Change Orders, Scope Creep, and who missed the requirements for heavy-duty chairs in the locker room. This meeting would probably be as calm as a Project Meeting to discuss a missing data field, a forgotten report, an untested piece of hardware, or implementation of beta code in a production. The lineman would probably be no more upset than the Chief Operating Officer who finds that the new database server sits outside the firewall because “nobody said we needed to keep the data server secured.”

The above situations need to be avoided, but they happen. Many projects are historically defined in terms of the amount of missing, misunderstood, or misrepresented requirements they contain. The Project Manager must be able to define the various aspects of the project in terms of scope creep, or missing and changed requirements.

Much of the time spent at the end of a project is consumed attempting to determine whether some newly discovered requirement is categorized as: (1) scope creep on the part of the customer; (2) a missing requirement that the Project Team should have included in the project; (3) or a change to an existing requirement that would necessitate a Change Request. In some cases the “change” is big enough to require a new Project Request be completed. The customer is not happy. The Project Team is upset with the customer. Everyone is blaming everyone else.

In these situations it is the responsibility of the Project Manager to understand the differences between what was in the project and what was not. The Project Manager must not be easily convinced or coerced into accepting the task as having been “missed” by the Project Team. This is much easier to say than it is to do. The easiest method of preparing for this situation is to manage the project in terms of requirements rather than tasks to be performed.

As an example, customers are frequently asked to sign-off on a project plan. The plan includes the necessary tasks to be performed by the project team. The customer is essentially only agreeing that the team members need to perform these tasks. That is all they are agreeing to with their sign-off. The customer is not agreeing that the expected project results are acceptable. They aren't agreeing that they agree that these are all the tasks that should be performed. All they are usually agreeing to is the extent of the process and the to the product.

Customer sign-off should be directed to the goals of the project. The customer should be responsible for the results that are to be achieved. The Project Team is responsible for the Project Plan. As team members go through the process of defining requirements and developing tasks, it should be remembered that each task should be directed at a specific aspect of the final product or service to be created as a result of the project. Many Project Managers include the customer in the planning phase or in project status meetings. This inclusion in the process frequently clouds the lines between product and process.

If a project is developed from the specifications provided by the customer and the customer is given specific details of the deliverable, it is not necessary to include them in the project planning process. The purpose of the customer in a project is to maintain the clarity of their expectations. To do this it is necessary to frequently confirm the expectations with the customer throughout the project, but it not necessary to involve the customer in the creation process.

The reason the role of the customer needs to be understood is that the customer must not be put in a situation where their top priority is not the communication of the expectations. The customer should never feel their priority is to define the tasks involved in achieving that priority. Frequent and complete openness with the customer regarding the project is necessary. Distracting the customer from their role in the project can be devastating.

It can be just as devastating to a project for the Project Team to become involved in the design of the end product or service. What will frequently happen when the customer is not yet clear on their requirements when they first meet with the project team is for the disparate priority of the two groups to become intertwined and specifications can be compromised. The customer may be told that some aspect of what they expect is not possible or it could be achieved some other way. The customer walks into this type of meeting with an expectation that is never actually realized because they compromised on issues before the specifications were completed. It is often not until the end of the project that the customer fully understands what they lost in these early conversations.

The Project Manager must be able to confirm at any point in the project exactly what was specified and what changes are being requested. In addition to his or her other responsibilities, the Project Manager is responsible for the management of change within the project. There must be a clear understanding of changes being undertaken to enhance the project and those being requested to enhance the result of the project.

For example, if a database is to be converted, as part of a project and the amount of time necessary to complete the database conversion is excessive, it may be possible to save time in the project plan by using bulk update techniques to build the new database. This is a process issue and not a product issue. The customer does not need to be involved in the decision to proceed with a bulk update. However, if there is a decision as part of the process that the database must be distributed instead of being centralized, as it is today, the customer must be involved because the deliverable has been modified. There is a fine distinction between process and product that the Project Manager needs to consider during the project. Misunderstanding this distinction is a common problem when confronting change requests and scope creep issues.

Making a List and Checking It Twice

During the project, the Project Team should maintain a “book of issues” listing the problems they individually encounter. This book should include items that are discussed with the customer and with other team members as the project proceeds. This “journal” should include every issue considered to be outside the scope of the project. As in the case of interviewing, it is important to note the specifics of who, what, where, when, why, and how the item was first exposed. This information can be used at the Post Project Review Meeting to discuss techniques to be applied in future projects to reduce the possibility of these same issues being raised.

At the Post Project Review Meeting the Project Manager needs to develop a set of criteria for future discussions with various departments that may be seen as contributing to difficulties in the project plan. There may be departments where the level of experience is insufficient to fully understand the requirements. There may be issues that resulted from changes in personnel within a department or functional activity. Companies or departments where there are higher than average personnel changes, flexible work hours or shift work, working from a home office is allowed, or where frequent travel is necessary can seriously impact project continuity. These issues must be noted and planned in future projects.

Another benefit of the “journal” is that is allows documentation of certain aspects of long projects that tend to be lost over time. As mentioned above, there are frequent changes in project scope that results from the changes in priority or expectation over time. These changes are easily managed if they are documented, but become difficult to manage if their source is unclear. Projects contain both a breadth, in terms of time, and a depth, in terms of resources and requirements. Many Project Managers fail to recognize the effect of time on the requirements. Influences outside the project can influence the project requirements. Documentation is necessary to the process of management of these issues.

The problem with the 30-year-old non-millionaire is that she had, at one time, felt she wanted to achieve the goal of being a millionaire, but seldom considered it in her plans. It was insignificant until her birthday when she found her bank account empty, and her 10-year-old car still parked outside her bedroom window in her parents' driveway. As time progressed from age 20 to 30 they should have been providing more definition to their goal. As they provided more detail they should have been diligent in determining the requirements to achieve the new definition. Finally, they should have been aware that change causes change.

Summary

The successful project meets all the requirements of the customer with sufficient detail that they feel ecstatic about the experience throughout the project life cycle. This level of completion is seldom achieved in Project Management but it remains a goal at all levels of project development.

Some effort can be made in delivering successful projects through an awareness and attention to detail. Much of this detail is revealed in the interview process with the customer. Techniques for conducting effective interviews and attentiveness to the requirements of the customer can serve to alleviate issues that will be obvious by the planned completion date of the project when the customer finds their expectations have not been met.

The Birthday Syndrome results from expectations based on limited experience, expectations that change over time, and expectations that are not clearly understood by the Project Team. Communication and clarification of expectations and specifications is necessary at all times and at all levels of the project organization. Roles must be defined and these roles must be maintained during the project to avoid wasted effort and confusion.

Using these techniques, there may more 30-year-old millionaires but there would surely be more successful projects.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA

Advertisement

Advertisement

Related Content

Advertisement