On the surface, requirements gathering would seem to be a rather simple process of just sitting down with the customer and asking them what they want. It’s been my experience, however, that requirements are a lot like minerals found in nature. They are rarely found in their pure state and require a great deal of refinement. You don’t want the customer to tell you that you gave them what they asked for, but not what they really needed.

I’m sure that many of you have seen the cartoon to the right that provides a humorous view on the requirements gathering process.  This cartoon is equally applicable for projects and products and if you have been involved in the process, your laughter may come along with some formerly repressed bad memories. The main point, of course, is how far a project can drift from the “real” customer requirements. But this cartoon also points out that customers often have difficulty describing their own requirements.

While very funny, this cartoon unfortunately tends to describe the norm, rather than the exception. This lack of understanding of the customer’s “real” requirements explains in part why many delivered software systems never achieve their desired goals.

While requirements gathering and analysis is hard work when done correctly, with few short cuts, it is not rocket science either. All it takes is just a little common sense.  While every project is different, potentially requiring unique approaches to requirements gathering, I have found two simple methods that have worked well for me in the past.

#1: Take Time to Observe

The first is just to spend significant time with the end user, talking with them in detail about their job functions, and observing them performing their duties. Years ago, while working as a systems engineer at a refinery, I was tasked with writing a process control program for one of the automated plants in the refinery. This proved to be a daunting task for two reasoning. First, a previous effort to provide this exact same function, implemented by a seasoned systems engineer, had failed. The second reason was my lack of previous experience with process control systems, and how this particular plant operated. Therefore, I spent several weeks just working with the plant operators, learning how they performed their jobs, and even assisting them with some of their tasks. I learned as much of their daily routine as I could. When I finally started to design and implement the process control program, I did so from the perspective of a plant operator, not an outside engineer. The system proved to be a success, in large part because I was intimately familiar with primary function that was to be automated by this program, including all the little nuisances related to that function.

#2: Refine Requirements with help from Customer Peer Groups

A group of key customer personnel that are representative of the people who will be using and managing the new system being created is an excellent refining source for the requirements. The primary purpose for this group is to meet periodically and review the system requirements and design, using prototypes to demonstrate and validate key requirements of the system. I used this process very successfully on a project involving the redesign of a grant management system for a large government program. Our user’s group consisted of approximately 25 people, representing all levels of users that would be directly and indirectly impacted by this new system, from the end-users all the up to the managing director responsible for that program. Throughout the development of the system, we met 2-3 days every quarter to review, validate, and refine the requirements. We made extensive use of prototyping to demonstrate those portions of the system reviewed during previous meetings. We would then incorporate this feedback into the design and make sure it was reflected in the prototypes used for the next meeting to validate what we heard.

As a result, the customer was able to visually see the system at all of its various stages of development, and provide critical mid-course corrections to the design. One positive side-effect of using this process was that the customer assumed ownership of the system as it was being developed. It became “their system”, exactly fitting their needs, not something just dropped on them at the conclusion of the project. As one might guess, they enthusiastically embraced the final product.

In conclusion, gathering and refining requirements is an iterative, collaborative process with the customer. It is not a passive activity, but requires hard work to get past the obvious needs to determine the often hidden secondary and tertiary requirements that play such a crucial role in the overall acceptance of the end product. You know you’ve been successful when the end-user remarks that whoever designed the system must have done their job before, because they addressed all of the little nuances that would only be known by someone intimately familiar with the entire process workflow making up that job.

Communications is a critical component of any successful project. It governs not only how well the project team works together, but also impacts the public perception of how well the project is going. Communications is a multi-faceted function that serves a variety of different purposes. I would like to focus on just two aspects of project communications; managing the customer’s perception of the project, and internal project team communications.

Managing a customer’s expectations of the project outcome is one of the most important jobs of a project manager. How often have you heard of a company having a real good earnings report, only to have their stock go down because they didn’t “meet analyst’s expectations”? For a project, not meeting expectations often results from poorly defined project requirements and deliverables, combined with inadequate communication of project status, causing the customer to assume capabilities that the project was never designed to deliver. Therefore, it is very important to explicitly communicate exactly what the project will deliver, as well as what it will specifically NOT deliver.

Keeping the customer apprised of detailed project status involves more than just holding periodic project meetings. These can be a big time waster if not properly structured and combined with other communications methods.

One ancillary communications vehicle that I have found useful in the past is to create/maintain a project notebook for each customer stakeholder.  While each project will have different communications requirements, the following list provides some examples of the content that I have found useful in the past:

• a detailed description of the project requirements
• important project milestones and deliverables
• all meeting minutes
• significant communications with key vendors contributing to the project
• internal project memos
• change request logs
• analysis/tracking of major project risks and issues/problems
• tracking of key project dependencies – especially with outside entities

Prior to each Prior to each Prior to each Prior to each Prior to each Prior to each project meeting with stakeholders, I send out revisions/updates to the project notebook reflecting the latest project status. This allows us to focus the meetings on important project issues and not waste time on the more routine status items.

You might reasonably argue that some of this information could be considered project minutia that wouldn’t be very meaningful to a project stakeholder. However, providing this level of detail tends to build an element of trust indicating that you’re not holding anything back from the stakeholders. In other words, you are making the stakeholders part of the project team, dissolving the typical “them vs. us” mentality that often exists between the project team and the end customer. Providing this level of information to the customer goes a long way in preventing unrealistic expectations from arising.

The other area of communications that is often undervalued is internal project communications. There is a school of thought that communications with team members should be confined to just those areas that they are working on, the theory being that it helps people focus on their individual tasks at hand, rather than being inundated with information extraneous to their function. While there may be some truth to this, my experience has been that some of this “extraneous” information actually increases people’s effectiveness because they are more aware of how their efforts fit into the global scheme of things. Furthermore, potential integration issues between major project components tend to be identified earlier due to this increased awareness.

A secondary benefit is that a well-informed project team functions more like a team, has higher morale, and presents a more unified project “face” to the customer (i.e. no matter which project member the customer talks to, they get the same information).

In summary, open and honest communications with the customer and internal team members increases the chances of success.  There is an old adage that if you don’t provide adequate information to people, they’ll make it up. Most projects have enough real technical challenges to deal with, without having to address issues caused solely by poor communications that could easily have been avoided.

(Strong project leadership and enlightened “people” management.)

I almost consider the term “project manager” a misnomer. Successful projects are “led”, not “managed”. Projects are too dynamic to lend themselves to just being managed. What are the hallmarks of a good project leader? I believe that a strong leader possesses a strong sense of purpose that instills confidence to the project team. A strong leader thoroughly understands the goals of a project, and the requirements to achieve those goals. They are also very decisive when faced with difficult decisions. A project team needs clear direction and quick conflict resolution. Lack of timely decisions or unresolved conflicts often lead to project objectives not being met on schedule, and can also lead to morale issues on the team.

An IT project should not be run as a democracy, but rather as a benevolent dictatorship. While it is good to obtain consensus when making major decisions, it should not be a requirement for the project leader to come to a timely decision. A project awash in indecision is ripe for failure. Also, once a decision is made, it should stay “made”, unless new compelling information comes to light that was not factored into the original decision. I have seen projects where the de facto project motto seemed to be that any good decision was worth making several times. This leads to confusion and wasted effort.

Part of being a strong leader is conveying a very concise message regarding the project goals and how those goals are going to be met. Just as important is a good understanding of the non-goals of the project (i.e. specific goals that the project will NOT address).  If you don’t paint a clear target, don’t be surprised if no one hits it. A strong leader creates this clear project focus by imparting an unambiguous understanding of the following to the project team:

1. The project goals – the team needs a crystal clear understanding of the project goals. These goals need to be simply stated and non-ambiguous. If you don’t know where you are going, how do you ever expect to get there. The team should also clearly understand what the non-goals are (i.e. the functions/ features/capabilities that are specifically NOT being provided by design). The level to which these goals are understood will directly impact the effectiveness and “correctness” of every major decision made in the project.
2. Each team member’s role in meeting the project goals – just as important to understanding the overall project goals is every team member’s understanding of their own individual roles in meeting these goals. Knowing where your tasks fit into the overall scheme of things provides the context necessary to disambiguate and prioritize the minor issues that always arise in the execution of individual tasks. In other words, it helps everyone in the boat to row in the same direction and not work against each other.
3. A conflict resolution process – the project team needs to know how conflicts will be resolved. A conflict can be a difference of opinion on some aspect of the project design, or any obstacle preventing someone from accomplishing their tasks. A strong leader resolves conflicts as quickly as possible to minimize their impact on the project (i.e. conflicts DO NOT improve with age).

Another hallmark of an effective leader is a good understanding of human nature. A project leader sets the tone of the project primarily through how they treat the project team. Team members need to be treated as individual people, each with their own personal aspirations, and NOT as project resource units. Everyone needs some level of affirmation for a sense of accomplishment. The project leader needs to know his or her team members well enough to provide the right level of affirmation to each person. Treating them with respect creates the type of atmosphere that successfully sustains the project team through the difficult times that often occur during the course of a project. Teams that are led through fear and intimidation often fail because this type of leadership divests team members from project ownership and discourages them from going that “extra mile” often required to get through the difficult times.

Finally, a strong leader NEVER takes credit for accomplishments rightfully belonging to individual team members or the project team as a whole.  A project leader’s success (or lack thereof) should just be a reflection of the project team’s success, and not measured by their own individual efforts.

Page(s) 26 in print issue

by Sixto Ortiz Jr.

Sidestep Project Management Landmines

Poor Communication, Lack Of Leadership & Other Problems Can Hamper A Project’s Success

Key Points

• Technical know-how, business acumen, and people management skills are all ingredients of successful IT project management.

• Capturing top management support greatly increases the odds for success.

• Risks cannot be eliminated, but they can be managed as long as they are identified in plenty of time.

IT project management can be precarious: Depending on which source is consulted, the failure rate for IT projects ranges anywhere from 30 to 60%. So, the odds are good that an IT project will fail to achieve its business case.

But, here’s a silver lining: There’s plenty of history documenting IT project mistakes. Administrators looking to steer a project to success should study the mistakes others have made in the past, especially within their own organizations. After all, those who don’t learn from history are doomed to repeat it.

Poor Definition Of Project Requirements

It would seem logical that an expensive IT project would have clearly defined objectives and a clear idea of the resources and outlays needed to get to the end zone. However, many organizations have suffered through poorly planned projects that ended up in the corporate scrap heap.

Unless everyone agrees on what is getting built, what the parameters are, and the rules for how things can change, the eventual outcome will be an unhappy ending, says Tony Navarrete, lead technical marketing in the IT Business Management unit of BMC Software (www.bmc.com).

“Early in the project definition stages, you need everyone to agree on the scope, high-level project budget, and key requirements,” says Navarrete. And, he adds, all of the stakeholders in the project must agree on these points so the project can move forward.

Harry Schultz, senior vice president of product development and solutions at Digital Reasoning Systems (www.digitalreasoning.com), says the true hallmark of a successful project is a customer that enthusiastically embraces the deployed system because it successfully addresses the specific needs that initiated the project in the first place.

But, says Schultz, the requirements-gathering process usually requires a significant commitment of time with the end customer to really understand their business and how the proposed system will be used. To accomplish this, Schultz recommends that a standing group of key customers (both technical end users and major decision makers) and key project members be formed to participate in the requirements definition process at the project outset.

Insufficient Communications

A complex IT project involves a substantial number of people working together toward one goal. A lack of clear communications can cause personnel to lose direction, focus, and ultimately the desire to see the project through.

One of the reasons projects often fail to align well with the desired value is because of inconsistent or inadequate interaction with the various sponsors and stakeholders, says Eric Willeke, lead architect for EMC Consulting (www.emc.com). To avoid this landmine, he adds, project leaders should focus a majority of their energy outside the project to ensure a clear understanding exists between the project team and the stakeholders. These communication channels, he says, allow potential impediments to be resolved promptly.

William Stuckert, vice president and general manager for Advanced Technology Services (www.advancedtech.com), says lack of communication about the business value of a project can have a negative impact on the people working on a project. Managers should clearly communicate the reasons a project is important to the business, Stuckert says, adding that this shows personnel the overall impact of their contributions.

Lack Of Leadership

Every undertaking must have direction from a leading individual. Without a strong hand to provide direction and leadership, a project may run aground very quickly, much like a ship steered by multiple captains who each wish to go in different directions.

Digital Reasoning Systems’ Schultz says successful projects require a project leader, not a project manager. An IT project should not be run as a democracy but rather as a benevolent dictatorship, he adds, because the project team requires clear direction and quick conflict resolution.

“A project awash in indecision is ripe for failure,” Schultz says. Strong leaders must convey a very concise message about project goals and how those goals are to be met.

Another dimension of leadership is ensuring that the person leading the project has the expertise needed to do so. But, says Jack Bergstrand, CEO of Brand Velocity (www.brandvelocity.com), the program director for a company is usually a respected business or technology executive who has never run a large IT project before. When that happens, this individual depends too much on the consulting systems integrator from the start, thus creating the expectation that the integrator will manage the project in a turnkey fashion.

Poor Risk Management

Projects are filled with unknowns at the outset, so determining what the potential obstacles are and the risks they pose to the effort is absolutely essential.

According to Alexander Magno, senior director of ADM North American Delivery at Keane (www.keane.com), a common mistake made by project managers is taking a “sit back and wait” approach to risk and attempting to solve problems once they occur. Magno says project managers should avoid falling into this passive approach.

The first step to avoiding this mistake, says Magno, is for team leaders to create a collaborative team atmosphere where openness helps identify and manage risks before they become issues. Second, he says, project leads should enable and coach teams so they consider the downstream impacts of delays, for example. Finally, mitigation strategies should be identified so the project team can work around risks and keep moving forward.

Lack Of Alignment With The Business

A project that lacks management support has a good chance to fail. After all, uncommitted top management is more likely to pull the plug on a project the first time things go awry.

For starters, lack of alignment with business objectives can cause project managers to “put blinders on” and neglect to account for market changes that cause a project’s business objectives to become invalidated, says Magno, who adds that it is important to keep business objectives for an IT project in mind throughout the process to avoid making this mistake. An executive steering committee should actively participate and review stated project objectives and business impacts throughout the course of the project, Magno says.

“Getting into the habit of recalibrating the project’s return on investment will help a manager remain ready and equipped to identify when to cut the cord,” he says.

Top Problem: Poor People Skills

People are the driving forces behind projects, so it stands to reason that project managers should be as good at managing people as they are at managing project logistics. Unfortunately, that’s usually not the case; Harry Schultz, senior vice president of product development and solutions at Digital Reasoning Systems (www.digitalreasoning.com), says many project managers have no trouble keeping up with technology but still don’t understand what motivates—and demotivates—people.

The solution? Management must treat people like human beings instead of resources and must value and respect their contributions. Also, he adds, respecting project members’ personal time, avoiding publicly berating personnel who make a mistake, and always showing appreciation will ensure people stay focused and contribute their best efforts.

There are many factors that differentiate a successful IT project from a mediocre one. Surprisingly, unsuccessful IT projects more often result from not following some simple “common sense” principles of leadership rather than not using the correct project management methodology or because the technology being implemented is too difficult. I don’t want to discount the benefit of all the new project management methodologies and processes available today, and their importance to a project. However, I believe that there are other intrinsic factors critical to the successful execution of a project that while being more subjective, are every bit as important as some of the more quantified aspects of project management.

My opinion is based on 34 years of working on a variety of technical projects, both as a participating team member and as the project manager. I admit that many of the important lessons that I have learned about project management stem from having done it wrong and learning from the experience. (i.e. good judgment comes from experience, and experience comes from bad judgment). I’ve worked on some extremely successful projects as well as participated in a few “death marches”. Through these experiences, I discovered some traits that were often present in the successful projects and absent from the unsuccessful ones. It is these successful traits that I want to explore further.

While there are many facets to these “success traits”, they all have at their core a basic understanding of human nature. Over the years, I have encountered some extremely smart people that while capable of keeping up with the ever increasing tempo of technological change, are clueless about what motivates and demotivates people. They appear to be unaware of the negative consequences of their leadership style and their impact on the project, and then wonder why their project is performing so poorly. It is like having a new car with a powerful engine and insisting on driving with the parking brake on, and then complaining that the car doesn’t perform as promised. I have actually had conversations with people that when I pointed out the “parking brake” in their situation, they were surprised that it would have an impact on their project.

I have never met a technology professional whose goal it was to do a bad job. Everyone wants to be successful and feel good about what they do. While sometimes people are miscast in their role on a project, too many times it is a culmination of these subjective factors that lead to poor project performance, not lack of talent on the individual’s part.

The following are four areas that have played a critical role in the successful projects that I have been part of over the years, and that I will be exploring in subsequent postings.

1. Enlightened “people” management and strong project leadership.

2. Adequate communications with BOTH the customer and the project team

3. Understanding the customer and how to determine their “real” requirements.

4. Risk analysis/avoidance (i.e. how to prepare for things going “bump” in the night”