Tag: Team

Seven Tips to Ensure Requirements Management Success

Written by Cynthia Low on March 24, 2009. Posted in Articles.

The path to building great software goes through requirements management. It’s easy to forget some times, but the world relies on great software. Software operates the cars we drive, the planes we fly in, the cell phones we can’t live without and the tools we use every day to get our jobs done. Software is everywhere.

As a software professional, you know all too well that software development isn’t easy. A software product is never completed. There’s always an opportunity to improve functionality and there’s no shortage of challenges to overcome along the way:

Lots of people involved in the process
Customers have difficulty articulating their real needs
Requirements constantly change
Teams are spread across multiple geographies
There’s growing pressure to release products faster
The complexity of software doubles every 2-3 years
More projects fail than succeed

Whether you’re building a revenue-generating product or an internal system, your company’s overall success largely relies on your software team’s success. And, the path to building great software goes through requirements management. Organizations that embrace this concept enjoy greater results. They experience fewer errors and frustration, faster planning and development cycles and they’re able to deliver higher quality products to their customers.

What You’ll Learn: The goal of this article is to provide you seven essential tips to help you be more successful with requirements management. For some, these tips might be new. For others, these tips will serve as a good reminder of the fundamentals that are easy to lose sight of during the heat of a project.

Tip #1. Stay Connected

You can eliminate most issues by keeping everyone connected.

Much attention is placed on the high failure rates of software projects, and for good reason. Any time there’s billions of dollars at stake and failure rates ranging between 60%-80%, people are going to pay attention. But, what you don’t hear as much about is the root cause. Last year, in The State of Requirements Management Report we polled over 200 professionals about the top challenges they faced in eliminating project failure, and the resounding theme boiled down to one thing – communication. If you can get connected and stay connected throughout the entire development process, you can eliminate the vast majority of issues.

Terminology	Simple Definition
Collaboration	Keeping your entire team connected throughout the development process
Traceability	Keeping all the requirements, artifacts and other related information connected

There are two parts to staying connected. First, there’s the connectedness of your team, which has been popularized recently as “collaboration” – new buzzword, same meaning. Analysts, project managers, developers, testers, product managers, executives, stakeholders and customers – is everyone on the same page about what you’re building and why?

Keeping everyone connected is often easier said than done, but it’s absolutely critical to the success of your project. Depending on the size and location of your team, you can do this manually through meetings, phone calls and documents or you can use a tool to help keep your team connected. It depends on your situation and the complexity of what you’re building. See Tip #7 for the tipping points when a tool might be valuable.

Second, there’s traceability – the act of connecting up the requirements and other artifacts such as use cases, test cases, tasks, defects and even user documentation – all the details that are related to each other within a project. For complex development projects, there can easily be hundreds or thousands of items involved and it’s critical to establish the traceability relationships between these items – both upstream and downstream.

For example, when a high-level business requirement changes 30 days into a project, through trace relationships you can immediately assess the impact it has on any downstream functional requirements, tasks and defects that a developer or tester might be working on. This helps minimize errors and costly rework because the team members affected are aware of the specific change and its impact.

Implementing traceability and a change control process that’s appropriate for your situation is one of the most important steps to ensuring success. As a simple first step to establishing change control, you can use a change request form manually to document changes right now.

Tip #2. Take Action Now

Don’t wait for your process to be “perfect.”

Doing something is better than nothing. It’s easy to fall victim to what you might call “process perfectitis” – a condition reached by teams that get paralyzed by process and analysis versus delivering working software. How many times have you heard someone say, “Well, we’ll get to that project as soon as we really lock down our process? ” Is any process perfect? More importantly, should that really be your team’s highest goal?

Whether your team is practicing some flavor of Agile or not, there’s one thing we can all take away from the principles of Agile – it’s that working software is the primary measure of progress. Don’t get us wrong, optimizing your process is important, very important. We’re constantly tweaking our process. However, if you have a better process and no product, you still have nothing to show your customers.

Doing something is better than nothing. Start small, identify a few critical requirements and take the approach of continuous improvement where you build, reflect, refine and repeat. Then, with each release cycle you’ll learn more about the needs of your customers and continuously improve and expand upon the software solution you deliver to them. If you think your team suffers from process perfectitis, look for these symptoms:

•· Requirements definition phase seems to drag on and on and on

•· In the last month more time when spent talking about process, while your product stayed the same

•· Lack of a decision-maker to make the call when to move forward with development

Tip #3. Eliminate Ambiguity

Successful requirements management begins with writing good requirements.

One of the things you can do immediately is make a “do not use” word list and post it up on the walls in your office. Visual reminders will help you to avoid using ambiguous terms when writing requirements. Karl Wiegers, a well-respected requirements management consultant, in his book Software Requirements provides a good list of ambiguous terms to avoid in requirements specifications. Here’s a snapshot of a few them.

Ambiguous Terms	Ways to Improve Them
fast	Specify the minimum acceptable speed which the system performs some action.
flexible	Describe the ways in which the system must change in response to changing conditions or business needs.
acceptable, adequate	Define what constitutes acceptability and how the system can judge this.
simple, easy	Describe system characteristics that will achieve the customer’s needs and usability expectations.
shouldn’t	Try to state requirements as positives, describing what the system will do, instead of what it won’t do.
robust	Define how the system is to handle exceptions and respond to unexpected operating conditions.

Source: Software Requirements by Karl Wiegers, 2nd Edition, Microsoft Press, 2003

Tip #4. Reconnect with Your Customer

You don’t have to be an expert to capture the voice of your customer – just committed.

This may sound obvious, but it’s easy to lose sight of customer needs as a project gets underway and the team gets to work building the solution. Keep in mind, we use the word “customers” to refer the end-users of the product you’re building – these customers could be external consumers for commercial products or internal users in the case of internal IT systems where other departments and employees are your customers.

Capturing the voice of the customer isn’t a one-time effort. Most project teams do a thorough requirements gathering session at the beginning of a project, but rarely does the customer interaction carry through to the end. Successful requirements management practices include constant communication with customers. Otherwise you risk falling into the classic trap of delivering a product that end-users reject because it doesn’t resonate with how they expect to use it.

There’s definitely an art to eliciting feedback and requirements from customers and clearly some people are better at it than others. There’s a plethora of books and courses out there to provide training for this specific skill. However, you don’t need to be a requirements management expert to capture the voice of your customers. The fundamental skill required is commitment. Commit to picking up the phone every week and talking to customers. Commit to getting out of your office and sitting down with customers in their real environments. These are things everyone on the team can do, and should do. Even in Agile it’s not always possible to have an on-site customer present, so you have to commit to getting that feedback other ways.

Here’s a quick list of Dos and Don’ts to follow as reminders for how to stay connected to your customers.

Dos	Don’ts
Be a journalist – ask open-ended questions	Think you know best what customers want
Talk to your customers every week	Assume past experience is representative of current needs
Be open and flexible to change	Assume customer needs are static
Just pick up the phone and call customers	Elicit requirements & feedback only at the start of a project
Listen with an open mind during elicitation	Sell customer on your idea for how a solution should work
Sit with a customer and watch how they work	Assume customers know how to articulate their exact needs
Close the loop with customers when their feedback has been implemented in the product	Forget to capture and share the evidence you gather with your team

Tip #5. Prioritize Objectively

Avoid building functionality that customers don’t need and may never use.

Development time is so valuable. There’s nothing more frustrating for everyone than wasting time building features that customers don’t actually use and don’t provide value back to your company.

This is where requirements prioritization is essential. You need to avoid the common pitfalls of building features that seem cool or that someone thought a customer might need. Too often, requirements prioritization happens subjectively. The team holds a meeting and in a debate over the requirements the loudest voice wins; or a request comes in from a salesperson who just spoke to a customer and the most top-of-mind request becomes the hottest priority du jour. With each new feature request or high-level requirement, ask these questions to determine if this is a must-have or a nice-to-have feature:

What percentage of our customers will benefit from it?
Does it fit our brand values and enhance a competitive differentiator?
What is the trade-off if we prioritize this ahead of other requirements?

It’s best to establish an objective prioritization model that quantifies the variables that matter most and that each high-level requirement gets evaluated against. That way, by getting agreement on the scoring model, it’s easier to get consensus on the highest priority requirements your team should focus on, objectively.

Tip #6. Minimize Overhead Select the right tools to get the job done.

If you’re a small team in the same office developing a fairly straight-forward product, you can use a whiteboard, task cards and daily face-to-face meetings to manage requirements. A specialized tool in this case could create unnecessary overhead. Likewise, if your team is building a product where the requirements are all agreed upon upfront and won’t change much throughout the course of development, then documents and periodic status meetings may work just fine.

As projects grow in complexity and teams grow in size and geography, so do the communication challenges and overhead of trying to keep everyone and everything in sync. It’s in these scenarios, where a requirements management tool can add value because the overhead of using the tool is far less than the manual overhead it takes to keep track of changes, manage trace relationships, update documents and communicate with everyone on the team.

Here’s a checklist of a few common tipping points where a specialized tool makes sense and can help reduce overhead by automating the process of keeping people and all the related information connected.

Variable	Tipping Point	Benchmarks
Complexity	The more complex the project, the greater the need. If you have over 100 requirements.	72% of teams have projects that on average have 100+ requirements.
Team Size	The bigger the team, the greater the need. If you have over 25 people involved.	Over 40% of teams have at least 25 members and stakeholders.
Location	The more geographically distributed the team, the greater the need. If 10%+ are virtual.	Over 60% of teams have at least 10% of their team working in different locations.
Change	The more changes, the greater the need. If you spend 10% or more of your time managing changes to requirements.	Over two-thirds of teams spend 10% or more of their time managing change.
Traceability	If traceability is a priority for meeting standards or government regulation, a tool is valuable for automating the management of trace relationships, change control and version history.

Benchmarks: The State of Requirements Management Report by Jama Software and Ravenflow, 2008

Tip #7. Don’t Reinvent the Wheel There are many existing templates and resources you can leverage right away.

Even though every company, project and team is unique, the resources needed to help you be successful, in most cases, already exist. In minutes you can do a search on Google and find a wealth of best practices information. As a starting point, here’s a link to more resources from Jama Software and Karl Wiegers for free companion resources to this article: http://www.jamasoftware.com/requirements_management_resources.php

Eric Winquist is CEO and founder of Jama Software. In March 2006, Eric founded Jama with the vision of providing customers a more collaborative way to develop new products and eliminate the common frustrations with traditional approaches to requirements management. Eric is an accomplished entrepreneur, business analyst and project manager with over 14 years experience working with a wide range of organizations. Previous to Jama, Eric founded Redside Solutions, a software development consulting firm.

John Simpson is director of customer outreach, Jama Software. John represents the voice of the customer and leads Jama’s product strategy and communications. John has over 12 years experience working at software technology companies including Microsoft, WebTrends and Omniture. He has contributed to several books, whitepapers and presentations.

They can both be reached through the following: 503.922.1058 [email protected] I www.jamasoftware.com 3/09

When Needs Become Conflict

Written by Richard Lannon on February 24, 2009. Posted in Articles.

Recently I was reminded that only 10 percent of conflict is extreme and that 90 percent of conflict is acceptable. In working with a client, I noticed some needs that were not being met. Those needs erupted into what we would call conflict between several people on the team. It was interesting to observe what took place. Mostly it was a flight situation. The people in the conflict situation left the area. This is not a bad thing as sometimes you just need to get out of Dodge. When it comes to conflict we all need to take some common thinking into consideration.

First, conflict has its positive place in our lives. Conflict is natural and depending on our disposition we might fight/flight or fend/befriend. We are wired that way.

Second, think of conflict like the ice berg in the ocean; two-thirds of it is underwater. For people the portion under water has to do with our history, values, culture, beliefs and feelings and all the other stuff that is happening in our lives.

Third, one-third of the ice berg is above the water. This is where we observe people behaviours. The above the water iceberg represents the actual conflict event that occurs among individuals and teams.

Conflict thinking is often broken down into four levels. These include:

Position: This is the level that is about facts, data, and information. At this level a person or team takes their position.

Standards: This level is about policy and procedures that do not necessarily fit the individual or team culture. Somewhere a change is mandated without regard to the people impact.

Objectives: There is a lack of alignment in the organization, team and individuals goals and priorities. People are confused and are not sure what is important. There are conflicting interests and generally poor leadership.

Culture: The culture level is about values, beliefs and attitude. This is the level where individual, teams’ and organizations’ interest lies. This level is the deeper under the water level that should be understood and taken into consideration. This level can represent a real challenge.

We all need at least one approach to conflict resolution. The following 10 steps is an approach used in dealing with one on one conflict that, if engaged correctly, can go a long way towards resolving conflict.

Present the issue without emotion, blame, or judgment
Ask for the other person’s point of view
Explain your point of view clearly
Clarify and define the issues in terms of both your needs
Create a joint plan with which you both agree
Brainstorm and discuss possible solutions
Select the best chance of meeting both your needs
Develop a realistic plan of action and determine who will do what, by when, where and how
Implement the plan, make a commitment to it and follow it
Evaluate the success of the solution based on the joint objective

During the conflict resolution discussion, do your best to keep your emotions in neutral. That does not mean divorce yourself from your emotions. It simply means that it is alright for both sides to recognize their emotions and feelings. Each party needs to acknowledge their emotions, be willing to describe the situation and express how they feel. In turn, they must clearly specify what is expected and consider the consequences of individual, team and organization behaviours.

Much of conflict resolution is about acknowledging and settling the emotions through collaborative problem solving to satisfy the various stakeholders’ interests to the greatest degree possible.

Richard A. Lannon partners with business and technology organizations to help clarify their goals and objectives and train their leadership and professionals on how to achieve them. He provides the blueprint for you and your organization to be SET (structured, engaged and trained). That is why his clients call him the SETability Expert. Voice: 403-476-8853 Email: [email protected] Web: http://www.braveworld.ca/

Embrace Change, But Make Sure It’s for the Better

Written by Cynthia Low on November 17, 2008. Posted in Articles. 1 Comment on Embrace Change, But Make Sure It’s for the Better

“Embrace change” is a useless platitude mouthed by managers or motivational speakers who have not thought through its full implications – or they are masochists who enjoy suffering. Changes that bring new opportunities or propel us forward are easy to embrace. But many changes look quite negative and are tough – if not impossible – to welcome. This list might include loss of a relationship, a loved one, health, job, money, and such.

We usually don’t choose the difficulties or negative changes that spring upon us. But we always choose how we respond.

Above or Below the Line: It’s a Critical Choice

For the past few years, I have been using a simple concept to discuss our choices in dealing with difficult problems. Surveys and feedback from my workshop or retreat participants continually point to the few minutes we spend on this basic model as the most powerful part of our time together. It may be basic and seem obvious, but many of us seem to need constant reminders and help because it is so easy to sink “below the line.”

There are grey areas slightly above and slightly below the line. This is “survivor” mode. When this is our response to a difficult change or problem, we’re sitting on the fence to see what might happen, or we are waiting for someone else to do something. There are times when waiting in survivor mode and not acting immediately is quite wise – as long as we are above the line.

Examples might be when we need more information and have to do some research, or to see whether a change is going to become a trend, or which way the new boss, government, or customer is going to go. The top of the graph – well above the line – is proactive “navigator” mode.

When we’re here, we’re trying to capitalize on the problem or change. Or, if capitalize is too extreme a word, we may be at least trying to figure out how we can make the best of – or work around – a bad situation. In this mind set we’re like the seasoned ship captain of old, he knew he could not control the wind and currents, but he could adjust the sails and steer the ship to make the best use of the winds and currents to move toward his destination.

Below the line is the dangerous territory of reactive “victim” mode. When we’re in this head space, we’re bitter, helpless, and feeling like others are out to get us or deliberately want to do it to us. In this “blame storming” mode we might point fingers at politicians, bosses or senior management, other departments, customers, competitors, and the like. Decades of research by University of Pennsylvania Psychology professor, Martin Seligman, shows that explaining events in our lives in this state of “learned helplessness” leads to lower performance, poorer health, and higher rates of depression.

What Pulls People Down

The feeling of helplessness shared by many people in their organization is a major contributor to low organizational morale. Here are some of the common causes:

Forces beyond our control. Mergers, acquisitions, changing governments, organizational power games, bureaucratic decisions, new technologies, competition, boom/bust cycles, security threats, dumb rules and forms, globalization, and such leave many people feeling like dispensable pawns.

Nobody ever tells us anything. In a world overflowing with information, most organizations have little open and transparent communication. So “us against them” rumors attempt to explain what’s going on and why.

We’re swamped. Many people’s e-mail inbox, voice mails, phone calls, and meeting schedules are overwhelming, as work encroaches on personal time and stress levels keep rising. This leaves many people feeling helpless and frustrated.

It’s popular. Cynics, doomsayers, and conspiracy theorists often get more attention – especially if they use disparaging humor, sneering personal putdowns, and mocking sarcasm.

Fear is more believable. In a Canadian poll probing irrational anxieties, pollster Allan Gregg asked, “If someone told you something was safe and someone else told you it was unsafe, which one would you believe?” He found that an astounding “68 percent would accept the message of doom and gloom” without questioning who was telling them and what they were talking about.

Society encourages victim thinking. People who make bad decisions to hold paper cups of scalding coffee between their legs while driving, drive drunk or carelessly, take drugs, or smoke cigarettes for 40 years are encouraged to “make somebody pay” for what they have done to themselves. Watch daytime TV talk shows for plenty of examples. Seeing positive possibilities in a calamity or making the best of a bad situation is much tougher than joining the crowd that’s given up and wants to play the poor-little-victim against some other group or external force.

It comes naturally. Most people can quickly identify what’s wrong. It’s less instinctive to focus on what’s right and build upon that. It takes much more courage to correct a problem than to point and complain about the problem while waiting for somebody else to fix it.

Shift Your Perspective: Life isn’t Fair

Lots of unfair and unjust stuff happens to undeserving people. Whatever hits the fan is usually not evenly distributed in most workplaces. But it’s our choice whether to stand in it or not. Taking a navigator response to difficult issues means facing problems head-on by focusing on what’s within our direct control or what we can try to influence. We then need to figure out how to let go of, or at least not ‘awfulize’ and give more power to problems or issues that can’t be controlled or changed.

It’s recognizing that the best thing to do when it’s raining, is to…let it rain. Here are some ways to be less of a victim and more of a navigator through difficult career or workplace changes: Be aware of your mental state and limit downtime – the ever popular and rapidly growing “Pity City” – or even its suburb, “Frown Town,” can be a therapeutic place to visit occasionally. We all need to grieve or vent our frustration when faced with major losses or setbacks. But don’t join any co-workers wanting to take up residence in Pity City (one workshop participant claimed her department head was mayor!).

That leads to deepening cynicism, despair, and inaction. Pay attention to your own moods and watch for defeatist language like “they will never listen,” “what’s the point,” “we’ve tried that before,” or “why bother.” Keep the problem in perspective – don’t get so drawn into the issue that it’s all you can see. Step back and look at the bigger picture. What’s going right? What’s working in your favor? How could this change lead to something better? What are the possibilities?

Talk through the situation with a colleague, mentor, coach, or spouse. Describing and discussing the circumstances will force you to re-focus on what’s happening – as long as you don’t commiserate with people who love to find conspiracies everywhere and be a victim. Dispute your doomsday scenarios. When your head is buzzing with dread and worry, examine your beliefs about this issue or change.

Challenge your thinking through weighing objective evidence against your fearful outcome. List more desirable alternatives or what you would prefer to happen. “Decatastrophize” your long-term fears by recalling all the times things have worked out successfully in the past. Examine and question the usefulness of dwelling on your feared belief or concern. Harness the power of imagery and counterbalance fears of what all could go wrong by ensuring you have a clear picture of what outcome you want from this situation. What would a successful result look like? What would you be doing with the key players involved? How would you be feeling? What mind set have you adapted to rise above the difficulties and problems? What actions might this lead you toward? Step back to step ahead. The busier and more frantic the pace of work becomes, the more critical it is for you to carve out personal reflection and renewal time.

Avoid the busyness trap of adding ever higher quantities of work time to compensate for the diminishing quality of that time, as you slowly burn yourself out. Set limits on your workday or workweek. Pursue hobbies, personal interests, or family activities. Get away on periodic mini and longer vacations. Meditate or learn other stress reduction techniques. Monitor and carefully manage your creative energy.

Change your self-talk – catch yourself saying things like, “I am too old to change,” “That’s just the way I am,” “He makes me so mad,” and replace them with more accurate phrases like, “I choose not to change,” “I am comfortable with the way I am,” or “I make myself mad when he says/does…”, or make action plans to change. Help pull others up In dealing with changes and problems in your workplace; you’re either part of the problem or part of the solution. Here are a few ways to help your colleagues or your team navigate more effectively through your endless challenges and issues: Speak up! Challenge, involve, or problem solve with those people who insist on picturing the worst outcomes and living in Pity City. By letting those comments go (or even worse, joining in), you’re allowing the naysayers and cynics to set your team’s emotional tone and spread helplessness.

Refocus their thinking. Focus discussions on solutions and the future, not on the past or why nothing will work. You might need to point out that raising complaints without possible solutions can be unproductive and even harmful to the team. If team members or co-workers insist on remaining a victim, you might encourage or even help them to find another job.

Celebrate progress. Look for small wins and steps in the right direction that you and the team can build upon. You might periodically list what’s going well, or list your team’s accomplishments.

Find healthy ways to ventilate frustrations. One team initiated a fine system whenever a member made a hopeless victim statement. It was a useful way to raise money for the United Way and called anyone to account for comments that brought the team down and poisoned their spirit. However, they soon found a need to vent frustration with the actions of another group or the challenging problems they were facing. So they added rituals like someone raising their hand at a meeting and asking for “permission to visit Pity City” for a limited time or scheduling a “grump dump” as part of their meeting agenda. It’s important to do a periodic “reality check” on how we deal with adversity and change.

One reality we can choose is to transform tough changes into positive results. Another possible reality is to wait for somebody else to take action or tell us how we should feel. Or our reality can be anger, bitterness, and helplessness. To choose our response is to choose our reality.

Jim Clemmer’s practical leadership books, keynote presentations, workshops, and team retreats have helped hundreds of thousands of people worldwide improve personal, team, and organizational leadership. Visit his web site, http://jimclemmer.com/, for a huge selection of free practical resources including nearly 300 articles, dozens of video clips, team assessments, leadership newsletter, Improvement Points service, and popular leadership blog. Jim’s five international bestselling books include The VIP Strategy, Firing on All Cylinders, Pathways to Performance, Growing the Distance, and The Leader’s Digest. His latest book is Moose on the Table: A Novel Approach to Communications @ Work.

Six Attributes of Leadership

Written by Cynthia Low on November 17, 2008. Posted in Articles. 1 Comment on Six Attributes of Leadership

Does leadership have an effect on project success? Is there a difference between management and leadership? Can leadership be learned? The answer to all these questions is yes. In this article, I will look at six attributes of project leadership. This is certainly not a complete list, just a start. One that I believe can help project managers achieve project success.

1. Think Laterally

The first attribute, lateral thinking covers a variety of methods to get us out of the usual line of thought. It is this kind of thinking that cuts across the instilled and predetermined patterns we all too often employ when working on a problem. With this type of thinking we try different perceptions, different concepts, and different points of entry and consider multiple possibilities and approaches instead of a single approach. Many problems we face as business analysts and project managers require different perspectives to solve them successfully.

2. Empower the Team

Often, there is little or no recognition for people who spend time on elementary problems, it’s the big problems that receive all the attention, yet, big problems start as minor problems. All too often, because of leadership attitudes, employees develop the habit of ignoring problems until they explode, at which time they become big problems, then leaders want to go on record for being a problem solver. Empowered project teams correct this attitude. They focus on getting the job done while solving or preventing problems while the problems are still minor.

The ultimate paradox of project leadership power is that to be an effective leader, one must turn all team members into leaders. In this way, processes such as relationships and the issues of leadership and empowerment become important. Successful leaders are able to motivate, to energize and to empower others. When people are excited and empowered, it affects both their task initiation and task persistence. That is, empowered people get more involved, take on more difficult situations, and act more confidently. Empowered people expend more effort on a given task and are more persistent in their efforts.

3. Be Optimistic

The third attribute is optimism. Leaders are optimistic. They think positively. Positive thinking is more than just avoiding negative emotions; there are actions and forethought involved. When negative events happen, excellent project leaders purposefully look for something positive. Instead of feeling that they can’t do something, they look at the problem as an opportunity for themselves, the project team, team development, bonding and growth.

4. Demand Better

On-going self-assessment and self-evaluation are critical for ensuring that your project is meeting its objectives and having a positive impact. Demanding better is actually a simple idea. All one has to do is ask, “What can we do even better?” Essentially that’s all there is to it. Asking the question over and over again focuses leaders on challenging themselves and team members. Further, it sets into motion an on-going self-evaluation and a focus on the process of achievement. In return, this focus on the process brings results.

5. Encourage Delegation

Delegation is one of the most important roles of your job; as a leader your job isn’t ‘to do, it is to gain or accomplish things through your team members. Your time should be spent on such things as visioning, motivating, controlling and goal setting, and not on trivial jobs such as fighting fires or responding to interruptions and correcting errors.

Delegating relieves time-pressures on you. It provides your team members with an opportunity to expand their own skills in decision making and problem solving and encourages their creativity and initiative, while motivating them to become what they are capable of being.

It forces you to spend time with your team members, thus developing your interpersonal relationships. Your feedback and attention will encourage them on to greater things. It helps set performance standards based on member’s accomplishments or results, rather than purely on their activity. It helps to increase results by releasing you from some of your activities. You will be able to step back and look at the bigger picture instead of being caught up in the internal activities of the project. You will be able to think outwards for the better of the organization and not lose sight of the real goals.

6. Reside in the Future

To meet future challenges, leaders must reside in the future. Only then can they set a vision with reasonable goals and promote the process of developing effective strategies to achieve them. Considering the future enables leaders to think constructively about it, and do the things that contribute to achieving their visions. Proactive future oriented thinking can lead to greater project success. The future will happen, no matter what we do. If you want a successful future, you need to work at it.

Victor Teplitzky is a Principal Consultant at Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. Victor is an Industrial Engineer and Behavioral Scientist (HRD/OD). Since 1974 he has provided training, consulting and assessment services to a wide variety of organizations in both the public and private sectors including; the National Guard, US Postal Service, National Institutes of Health, Sara Lee Corporation, DoE, DoD, GPO, USACE, FAA, Wal-Mart, The Hartford, ING and many more Fortune 100 and Global 2000 companies. Victor has designed and developed over 100 training workshops including both general programs for “off the shelf” presentations and workshops tailored to meet specific client needs in the areas of Project Management, Business Analysis, Professional Development and Business Development.

Defining Requirements within a Short Time Frame

Written by Cynthia Low on October 15, 2008. Posted in Articles. 3 Comments on Defining Requirements within a Short Time Frame

Recent industry studies show that modern software projects on average spend 40 percent of their effort on rework. As a result, over 60 percent of software projects overrun budgets, miss schedules and substantially reduce delivered functionality. Without a clear idea of how to set requirements, most software development projects will face either significant rework or fail altogether. Over the past few years, Agile methodologies appear to be helping reduce this problem. This whitepaper will explore techniques of capturing requirements within Agile teams.

Wikipedia says that, “The term Agile Software Development refers to a group of software development methodologies that promotes development iterations, open collaboration, and process adaptability throughout the life-cycle of the project.”

So, if we apply a sports analogy, using Agile methods to develop software is like a series of sprint races. Developers are focused solely on successfully completing the next iteration, which is often due within a matter of weeks, and they zero in on defining their requirements to achieve that short-term goal.

In other words, Agile teams don’t produce any requirements specifications that are not absolutely critical to making it clear to the team what is expected of them in the short term. So, the question becomes: How do you decide what requirements are “just enough” to complete the next iteration?

There are a number of factors that need to be considered, when deciding what techniques and how much level of detail to provide when defining requirements for an Agile team. These considerations should include:

Team size and the proximity of team members
Skill and experience of the team
Has the team worked together before?
Complexity of the requirements
Complexity of the software.

Keeping the above considerations in mind, you will need to decide which techniques you will want to use and how much detail you will want to provide while using these techniques.

Common techniques include:

Verbal Communications. Verbal communications, perhaps using a whiteboard to capture key thoughts, is typically the fastest way to define a requirement. However, what this approach makes up for in initial speed, it doesn’t ensure that all stakeholders are in the loop. Plus, participants may not all remember exactly what was decided after the meeting breaks up. It is all too easy to have a different recollection of details that were discussed two weeks ago. This can lead to misunderstanding of requirements during development and testing, and will be reflected in inaccurate product user guides and training material. So you may have saved time initially, but wasted more time in the long run.

So when is verbal better than written communication? Agile methods promote face-to-face interactions, but that can be impractical in cases where teams are scattered across the globe or even across a city. Relying only on verbal communications is a last resort, to be used only when short-term time gains are worth more than the longer term problems this approach can create.

Story Cards. A popular and valuable technique within Agile development teams is to create a story card. These story cards tend to provide a text-based description of who wants to do what and why, along with perhaps a picture of the screen and some test scenarios. This technique works well for very small features but may not scale well for larger or more complex features that integrate and depend on other features.

Requirements Lists. Often a common place to start from a product scoping point of view is to create a hierarchical “Requirements List” which captures in text form an organized and grouped list of functional requirements, technical requirements, business drivers etc. Often these text descriptions can be enough to clearly articulate what the requirement is For example a technical requirement such as, “The application must support IE 6 and IE 7,” does not really need any additional explanation. However a requirement such as “The application must be able to define which users can have access to specific functionality and data” will need much more detail. The point is to only expand on requirements that truly need more details.

Use-Case Flows. Sometimes to truly understand the overall flow of a more complex requirement use-case flows or simulations are required to capture “just enough” requirements. However from my point of view it typically is not a good idea to use “use cases” to document complex logic or business rules such as authorization logic. These types of requirements are often better documented in text or tabular formats. For example, a simple 2×2 table showing the roles on one axis and what they can do on the other axis is a much more efficient way to convey authorization business rules than embedding alternate flows into use cases.

Simulations. Simulations can add great value to really bring a concept to life, but adding every single detail into the simulation can take too much time. And, frankly, it is sometimes difficult for developers to reverse-engineer a simulation and extract a discrete set of requirements. It is much easier for an Agile team member to read a simple table showing who can do what, than to run through a simulation and reverse-engineer the same information. Also, it is possible to spend too much time doing elaborate simulations that don’t add enough value for the time and effort they can take to develop.

Everyone will have their personal preference as to when to use what technique for communicating requirements, but the key is for the team to work together and agree upon when it makes sense to use different techniques and not “force” a technique when it clearly can be done more easily another way.

General Repository. No matter what techniques you decide to use to document requirements, keeping these requirements details/artifacts in a central repository and linking them to each other in an organized manner is critical to the collective success of your Agile team. Relying on people to keep track of endless email trails and simple document repositories with manually maintained links is not the answer. People are too busy to do it, and, most likely, the data repositories will not be kept up-to-date. Because of that, any repository needs to do whenever possible to automatically create and maintain these links based on how the artifacts are organized. For example, if a use case refers to a screen on a given step, then that screen should be automatically linked to that step in the repository.

So how do you know what is enough detail? Your team will let you know when things require more details. Part of working within an Agile team is to expect the need for requirements clarification throughout the project. In traditional waterfall, this was almost discouraged and under the good intentions of change management. However, within Agile, it is expected and embraced, which takes some getting used to for Agile newbies.

Recap

This topic is much deeper than can be covered with this small article, but the key points are

Make a conscious decision on the level of detail you want but expect to tweak that during development.
Choose the right technique for the requirement you are trying to describe.
Make sure you keep an integrated central repository that links together the multiple requirements artifacts.

Martin Crisp is CTO of Blueprint Systems. He can be reached at [email protected]