Tag: Best Practices

A Dressing Down for Business Analysts

Written by Robin Grace on July 11, 2011. Posted in Articles.

BA: “They didn’t participate in my workshop. Again.”

Mentor: “You must be mortified.”

BA: “Seriously, they come up with these lame excuses: they don’t understand that computer stuff, they’re too busy, or they think it’s a waste of time. One even told me to just get it done and let him have a look when I’m finished. How must I fathom the requirements myself? And they call that idiot a professional.”

Mentor: “You sound like a stuck record. Every other week you stomp in here ranting about the users, the stakeholders, the so-called professionals who waste your time. You always blame everybody else.”

BA: “So now it’s my fault?”

Mentor: “When I was a green analyst I had the same problem. You know what I did?”

BA: “Hired Chuck Norris?”

Mentor: “I went back to basics – I started planning properly.”

BA: “Planning? First it’s my fault and now I did not plan! Well I did plan. I planned for all those morons to attendmy meeting this morning – I even bought muffins, for goodness’ sake – and none of them arrived. By the way – you want a muffin?”

Music to a BA’s ears

If I had 100 dollars for every time I heard a BA complain about the stakeholders not participating in their meetings I would have – and I am not making this up – exactly 87 bazillion dollars and 50 cents. The big problem with people not participating in your meetings is that by the time you see a room full of empty seats it’s too late. The damage is done. You see, getting stakeholders to your meetings starts long before you even call a meeting.

In fact, it begins with a classic film: “The Sound of Music”. “When you read you begin with A, B, C. When you sing you begin with Do-Re-Mi.” And then you have the lines, “Doe, a deer, a female deer,” and so on. The point is that you begin at the beginning and the beginning of any BA project is planning.

So, as my fictitious friend asked earlier: What does planning have to do with putting people in the seats? For starters most BAs I come across don’t do enough, if any, planning, yet the Business Analyst Body of Knowledge (BABOK) clearly has an entire chapter devoted to it – Chapter 2 to be precise. Some of you may argue that you do plan. You create lists of stakeholders, you assign roles and responsibilities. But, on closer inspection, most BAs think that copying and pasting a list of stakeholders from some other project is a substitute for planning. It isn’t. There is no way around it. If you copied and pasted then you did not plan.

The list is important because it is the very first step the BA, that’s you, takes in understanding who does what, when, how, where and why. And if you don’t know that then you cannot convey any sense of understanding, relevance, or importance to the stakeholders. And without those only the soft-hearted will attend your meetings.

The BA communications plan describes how we will communicate with the stakeholders. Any stakeholders on the list that have an RACI “C” next to their name must become part of the elicitation process. Most often we will “C”onsult with them in a requirements workshop. We have to inform them of when we would like to “C”onsult with them and exactly what we will need from them.

It all makes perfectly good sense because you are ensuring that the right people are involved and that they know what is expected of them. The next thing you do is get their consent, their approval, because that leads to buy-in. You’ll need them to agree to what must be done, when it must be done, and who must perform each activity to gather all the requirements. There is also an implied contract that the BA needs those people to do their work for the sponsor and, if they don’t pitch, they are wasting the sponsor’s money. One way of getting that message across is through the content of the invitation to the workshop. Suggest that the participant’s involvement is crucial to the success of the project and that the sponsor is aware of this. If the sponsor has any organizational clout, it’s the added incentive stakeholders need to be there and be on time. In other words: wag the big stick.

The BA and the Paperwork

What you’ve done by ensuring only the right people attend the meeting is that nobody’s time is wasted. You don’t have people sitting around wondering why they never said a thing, never contributed to the proceedings. That quickly annoys people, particularly the busy ones These same people are the oneswho are important to the project at some point, if not right then. Having only the right people at meetings also makes the meetings move along more swiftly. Shorter meetings leave people more inclined to attend future sessions. More focused meetings with only the necessary people in attendance, also finish more quickly because everyone is driving to the same clear goal. So where do you find the required participants? You go back to your stakeholder list and communications plan, which should identify who should be present for the process under scrutiny and it’ll be correct because you didn’t just copy and paste.

The next item on your busy agenda is language. Imagine the conversation at the beginning of this story being between a BA speaking Russian and the mentor speaking Cantonese. They’re probably going to get things a little muddled and may even end up becoming frustrated with each other. By the same token you need to speak the language your stakeholders understand. If every other word you use is jargon that only BAs understand, then your stakeholders will quickly get bored and start imagining the fantastic little getaway they’ve arranged for the weekend..

Context is king. Put the meeting in the context of your stakeholders so that they can understand the reasons why they are there in the first place: “I know you have customers and they place orders; tell me more about what you do when you receive a customer order.” It focuses the workshop immediately, the participants feel you understand what they do, and it shows you value their time enough to have done some groundwork.

If you do all of these suggestions, through careful up-front planning to obtain a focused, contextualised outcome, then stakeholders will quickly feel appreciated and relevant and possibly even enthusiastic about your meetings. OK, maybe not always enthusiastic. But you will be able to imagine a completely different conversation to the one that opened this story.

I always say: If you can show business real value in what you do, then business will start to really value you.

Don’t forget to leave your comments below.

The Role of the Implementation Consultant – 3 Things You Must Know!

Written by Remzil Kulkarni on July 5, 2011. Posted in Articles. 1 Comment on The Role of the Implementation Consultant – 3 Things You Must Know!

Congratulations! You’ve just won your first large client and you are being chosen to play the role of the Lead Implementation Consultant for the engagement. You are being chosen because you are, at your core, an excellent BA and have a very high level of expertise about the product or solution that has just been sold. You will now be the one chiefly responsible for understanding the client’s requirements and , as far as possible, addressing gaps so that the solution or product that has been sold will meet your particular client’s needs.

While the role of an Implementation Consultant sounds (and in fact is) very exciting, there are few things you must know before you dive head long into the shoes of an Implementation Consultant. It is obvious that knowledge of business analysis is critical to succeed at this role. However, this article is not about the art or techniques of how effective business analysis is performed. There are far too many guides, models, and other bodies of knowledge that cover these essential tools.

What then are the other things any Implementation Consultant should be aware of? The things you should pay heed to and have a strategy for comes from a finer understanding of the role of the Implementation Consultant itself.

The Role of the Implementation Consultant

Typically, the Implementation Consultant is hired by the product or solution provider; and while they may consult with the client or customer for the duration of the Implementation, they most probably will return to their employer to be staffed on some other engagement once the current implementation consultancy is done. In terms of long term association and who is responsible for job security, the employer has the upper hand.

As a consultant to the client however, the Implementation Consultant needs to build strong and lasting relationships with the client. The Implementation Consultant will be one of the major representatives to the relationship the client will have with the provider. The key to any strong relationship is trust. Essentially, the Implementation Consultant has to perform his/her role by staying true to the client’s interests, and thereby build a relationship built on proven good faith and trust.

While this may sound relatively easy, it can be very tricky, meeting both your employer’s and customer’s goals and meanwhile doing what’s right for the role itself. However, by bearing in mind these important keys to the trade, you will find yourself far better equipped to perform effectively, rather than if these situations catch you off-guard.

Handling Conflict – The Implementation Solution Roadmap

While managing conflict sounds easy, most conflicts arise when what the customer truly wants would involve extensive changes which they believe cost relatively nothing. In return, the provider would like to propose alternatives that might meet certain parts of the requirement but probably wouldn’t agree to do exactly what the client wants or has requested.

In liaising between the two, the conflict often lies in whether the Implementation consultant should be true to his/her employer, recommending what they would prefer, or honoring the trust based relationship they have established with their customer.

However, the best way to handle conflict is to study the requirement and determine what’s best for that particular implementation, irrespective of what the customer says they want, or what the provider says they can (or are willing to) offer. This involves understanding true business value and clarifying these concepts into measurable processes or results.

For example, while the client may want a user interface for entering batch data (multiple rows), the customer might provide an interface to accept data one record at a time. The true solution to the requirement might not in the end be either what is requested or offered! The Implementation consultant should investigate the source of the data, the volumetric data involved, the business process and goal, and offer a solution based on these aspects of the requirement. For example, it is very likely that the implementation consultant might suggest an EDI file upload, which would bring immense value in terms of reducing data entry effort, face to face time with the system and increase the ability to perform a key function more quickly and easily.

Configuration Vs Customization

In terms of their responsibilities, the Implementation Consultant is in charge of understanding the client’s requirements and suggesting how best these requirements can be met by the proposed product or solution. While every proposed product and solution will have gaps, over-architecting the means to address gaps can be the biggest pit an Implementation Consultant can fall into.

In such situations, the goal of the Implementation consultant should be to address all gaps via “configuration” rather than “customization”. Configuration level changes are made to settings that do not require the code to be rewritten and the executables to be rebuilt. Customization, on the other hand involves changes to the code which are custom built or specific to this implementation.

Confining most changes to the Configuration realm will allow quick and effective changes to the product or solution rather than long drawn out changes which will require time, effort and money! This strategy also allows the client to get the best out of a ready to ship product or solution where their time to market is minimized.

Industry is recognizing the importance of this principle and it has resulted in the popularity of the widely hailed “SaaS” or Software as a Service model. Most organizations follow the 80-20 rule where gaps which can be addressed by customization up to 20% of scope is acceptable, beyond which it’s not advisable and would tend to reduce the benefits you get from a proposed product or solution.

Changing the Business Processes

Every product and solution will have a logical process that runs through the lifeline of the product. When a customer purchases a product or solution, most want to have the product or solution changed to match their business processes. In fact, most customers will realize value by changing the way they do things to match the inherent process present in the proposed product or solution.

While I’m by no mean suggesting a major change to a business model or making an existing business process ineffective, quite a few business processes in use in an organization have evolved as a result of the demands of the current infrastructure. A typical example of such a process would be how a particular department processes dividend payouts which would involve steps such as recording the dividend announcement, the dates and the rates, isolating the qualifying payees, calculating the amounts, clearing payments, reconciling differences and finally processing payments. The order that an organization performs these steps could very well be a dictate of how their current solution processes this task.

Rather than carry these types of processes forward to the new implementation, however, it is absolutely essential for the Implementation Consultant to explain what business process the proposed solution expects and encourage and drive change within the customer’s organization to suit it. While regulatory processes, for example, will not be subject to change, certain other processes such as the one detailed above should be redesigned based on how the new solution works.

In Summary

All said and done, the role of the Implementation consultant is tricky, complex and very influential. How well this role is played out can make all the difference between a successful implementation that is the canvas for a case study and one that turns out to be a disaster, retold for years to come about how things can go wrong.

Every Implementation Consultant has to play the base role of a Business Analyst over and above which they have to manage the direction of the implementation. Being aware of the 3 key aspects of implementations we’ve talked about will help guide your implementation down the right track, and ensure your customer gains the maximum benefit out of their investment in your solution.

Don’t forget to leave your comments below!

Remzil Kulkarni has over 15 years of experience in technology enabled business transformation focused on Insurance, Telecom and Finance. She has a Masters degree in Engineering Management from Southern Methodist University, Dallas TX and is President of the IIBA Pune Chapter. She is a certified Prince2^TM Practitioner and a Fellow of LOMA ( FLMI ). She currently heads the Business Analysis Centre of Excellence at Mastek Ltd., where she has worked for the last 5 years.

Business Analyst Says: Do Something Worth Remembering

Written by Teri McIntyre on May 24, 2011. Posted in Articles. 1 Comment on Business Analyst Says: Do Something Worth Remembering

All I did was create some pretty-looking clouds. You would have thought I invented clouds.

“Do something worth remembering.” So said Elvis Presley, who did many things worth remembering, like his infamous pelvis shake and those peanut butter-banana-bacon sandwiches. But how often do we take the time to recognize whether we have done something worth remembering in our careers?

As practicing business analysts we do ‘things’ every day. The requirements are gathered. The stakeholders are identified. The documents are written. The hands are held. This is all expected work, rote work if you will, of a business analyst. And certainly we love what we do, routine or not; we remember all of it. But is any of what we do in the daily grind worth remembering once the project is over, once the deliverable is delivered, once the milestone is achieved?

I go with “No.” Many a project has crossed my desk over the years, and mostly they stand out now as comprising lines on my CV. I don’t want to give the impression that I move on and forget everything that came before. I do remember all the projects I’ve worked on and often refer to past work as part of a future project. However, it is on the rare occasion that I can narrow in on some accomplishment or action which bookmarks a project as being unique and worth remembering beyond the advantages of a new career experience. We should strive to do something worth remembering, not just something that can be remembered, to give those experiences a little extra ‘oomph’.

I’m talking about the things that become humorous anecdotes relayed to friends over drinks or creative examples provided to a potential employer in an interview. These may be big ticket things but often these are the little things that get overlooked in the daily grin, that get lost in the purgatory heat of getting the job done and getting it done well.

One such bookmark for me centers on the aforementioned pretty-looking clouds. They started as a quick means to an end and wound up being something worthy of remembering not only for me but more importantly for my client.

It all started innocently enough.

I participated in a large-scale corporate website renewal project last year. By the time I was assigned to the project, the organizational unit owning it had already solicited two external reports on what needed to be addressed with the renewal, completed an RFP, and hired a consulting firm to complete the design by the time I arrived. This all sounded great until I started reviewing the consultant reports and the RFP. It became clear almost instantly that the scope and requirements for the project were ill-defined. Not only was the cart put before the horse, but the horse was completely absent from the landscape.

Never one to back away from a challenge, I furrowed my brow to figure out how to quickly elicit the missing business requirements to fill in the blanks. What I knew from the RFP and the project sponsors was that the organization needed a new website and that it was going to happen. Not a whole lot of insight there. I also knew from these two sources that I couldn’t re-interview or meet with the stakeholders regarding the requirements; these individuals had already been through two rounds of interviews with the consultants and had participated in multiple in-house discussions before my arrival. They were agitated by the lack of project progress, and it was strongly advanced that if I went the interview/discussion route again the project could collapse.

I heeded the advice wisely and devised a tactical plan of attack. After all, one reason I was brought into the project was to diffuse this agitation not exacerbate it. Luck was on my side when one of the project sponsors casually mentioned that the consultants had provided the interview transcripts along with their final deliverables. I combed through this source material and determined that the business requirements could be synthesized into five major themes. With this step complete, I took those themes and broke them down into accompanying requirement groups or business functions that would prioritize the functional and content requirements work later on.

While this achievement was thrilling for me, I knew no standard template or approach was going to work in the presentation of this information. I needed a hook, something creative that would grab the attention of these disgruntled stakeholders and keep it long enough to peek my head through opened door and win their preliminary support for further requirements work.

In a late-night rush, I decided to (a) present a picture of the themes (themes were limited to titles of three words each), (b) present one quotation culled from the interview transcripts for each theme, and (c) present the picture as a cluster of clouds to represent my own brainstorming activities on the project. There were three reasons informing my decision:

It was a website project so the stakeholders were open to a ‘non-traditional’ approach.
A picture would represent to the stakeholders an investment of my time and effort in understanding the project.
The text quotations would demonstrate to the stakeholders my investment in listening to what they had to say.

Portraying the latter reason was critical – I needed to present their words back not only to demonstrate my investment but to also attune them to understand that they were invested in the project too. For as disgruntled and unhappy as they were by that point, they needed to be reminded of their initial investment and enthusiasm for the project. This meant finding the right quotations; I couldn’t just pick any collection of words that fit the theme. They had to resonant as much as the visual, if not more.

I’m now irrevocably associated with “the clouds”.

Well, to say that the clouds were a success would be a serious understatement. I created the one-page picture and sent it to the project sponsors first. Unabashed glee may not be the best description of their reaction but it is darn close. Excitement for the project ratcheted up immediately within the project team and I was off and running. I presented it to the stakeholders next and the response was just as positive. I had hit the nail on the head.

The effort spent on the quotations paid off too, as people embraced the exactitude and simplicity of the words I presented back to them. They started trying to figure out who said what, sometimes even mildly arguing over credit. Through a single afternoon discussion we all arrived at the project muster point I desired: it didn’t matter who owned the quote, what mattered was the depth of commonality across the entire stakeholder group in understanding what the project needed to achieve. It didn’t matter that Person A said the words; it mattered more that Person B through Z also agreed with the words.

With the commonality recognized and accepted, great things started to happen. Those stakeholders that were still in the project, but were ready to bolt, started voicing their frustrations constructively and engaging with the project in a more active and optimistic fashion. In fact, the one stakeholder I was told would never get on board became one of the project’s biggest supporters. As well, those that were still engaged but with low enthusiasm started increasing their engagement as well and translating their increasing enthusiasm into actionable tasks and positive commentary.

That one-page document with the pretty-looking clouds became the lynchpin for the project. Whenever the project appeared to stall or lose some momentum, out came the clouds. Whenever an external party questioned the work and scope of the project, out came the clouds. Out came the clouds everywhere. It became a punch line of sorts; “remember the clouds!” was a familiar refrain throughout the early weeks. One of the project sponsors even talked about having a t-shirt made with the clouds that she could wear to executive meetings and presentations!

With these pretty-looking clouds, I did something worth remembering without any expectation of doing so. A creative, tactical gamble paid off more than I anticipated. For me, the clouds got the job done; for my clients, the clouds got the job done well. I won’t be remembered for the deliverables or the content audit or the many other routine tasks I completed to successfully implement this project. I may not even be remembered at all in five years’ time. But those pretty-looking clouds will be, and it is satisfying to know I played a central role in their creation and longevity.

So, do something worth remembering. And not just for your clients or for a promotion or some reward, but do it for you. Go outside the boundaries for the standard rules of engagement. Take risks if the circumstances warrant it. Make it a habit to reflect on your work beyond what you needed to accomplish and take stock of the worth of your contributions. Such reflection will make you a stronger business analyst and reveal opportunities you may not have conceived of as being possible.

Don’t forget to leave your comments below.

Teri A McIntyre, MA, CBAP, is a principal at Charann Consulting, providing business analysis and project management services to public and private industry. She is a Libra/Tiger, which scares and pleases her and her clients simultaneously. She adores analytical work and getting in front of the clients but rebels against putting a pre-conceived box around how such activities should be completed. Personal philosophy: “Why should a painter work if he is not transformed by his own painting? – Michel Foucault

So How’s That Working for You?

Written by Mark A. Monteleone on May 24, 2011. Posted in Articles.

Often while teaching business analysis, students ask me, “Why should our business adapt any of these business analysis techniques? We don’t use these techniques because they take too much time.” My initial response is always, “So how is that working for you?” This open question requires not only an elaboration, but some thought and not just a quick response. It is also an effective question that allows me to start a dialogue with the student rather than a discussion defending the use of business analysis techniques.

The word dialogue in Greek means to “talk through” as opposed to the word discussion which is derived from the Latin root meaning “dash to pieces” (1)

As the students ponder, I follow-up with some more focused questions to “pull” information from the student rather than immediately “push” my opinion onto the student. “How are your projects performing today? Are your expectations being met?” These questions, of course, assume that they are tracking projects via measurements. And by measurements I am not just talking about being on schedule, within budget, and delivering the stated scope. I’m including the delivery of the benefits and/or compliance issues as stated in the project business case (discretionary and nondiscretionary projects).

Often, project benefits are not realized until after project closure; therefore, they need to be tracked at the enterprise level.

Continuing with the follow-up questions, “Does your business actually audit the business results? Or does your firm declare victory upon the completion of a project and then move its attention to the next endeavor without any reconciliation of the business needs actually being met?” Unfortunately, many firms only measure the project level “triple constraint” (time, cost, scope) while the tracking of the business results at the enterprise level goes unrecognized and unrecorded.

Success is not gained from the project execution, but in the business result it provides.

Using active listening, I gain a better understanding of the students’ experiences. Typically responses to my initial question are the following:

“Our project performance is good; our projects generally come in on time, within budget and deliver the committed scope” or
“Not so good. We have experienced some challenges in maintaining project scope along with unclear business results.”

With the former response, I advise the students if they feel project results cannot be improved then don’t change. Of course, in reality there is always room for improvement; it’s just a matter of cost vs. benefits. Along with this, I recommend that students consider benchmarking their results with other firms in their industry to ensure they are not missing an opportunity. Competitors may have found ways of achieving better results, not only lowering cost, but gaining new revenue and deteriorating your firm’s market share.

Those who do not monitor their competitors soon find themselves working for them.

With the latter response, I advise the students that business analysis techniques lower the risk of maintaining project scope and ensuring business results. These techniques are best practices and as best practices, they are proven to be effective and efficient in analyzing business requirements and process improvements. Some of these are:

Using the diagnostic approach
Modeling the current (AS-IS) and desired (TO-BE)
Determining root cause of problems
Measuring performance via metrics
Involving users
Building a business case
Defining and validating requirements iteratively
Tracing requirements back to the business need

I suggest to the students that they have before them the opportunity to help explain to their firm how business analysis techniques at both the project and enterprise level can improve their business results. Their first step is to list the threats and opportunities for their business. They can then gain support by developing stories that predict both positive and negative results for their firm.

Business analysis techniques lower the risk of maintaining project scope and ensure business results.

This means, of course, that their firm must change their current posture and adopt business analysis techniques at both the project and enterprise level. Unfortunately, history shows that human beings typically are not motivated to change until they reach a cusp of a crisis. Hollywood portrayed this behavior recently in a dialogue between an outer-space alien and an earth scientist on changing the nature of human beings to save the environment of their planet (2). In this context, the key is for the firm to change prior to the demise of the business.

For change to happen, a sense of urgency needs to be established.

So in conclusion, “How is that working for you?” If your answer is “not so good,” then you have an opportunity to take the Kotter’s first step in changing the organization – state a sense of urgency (3). Start a dialogue on addressing the business threats and loss opportunities of not achieving business results (i.e., a business case). After you have established the urgency (As-Is model), establish a team, define a vision (To-Be model), and conduct a gap analysis on how to make the transition using those business analysis techniques. Yes, business analysis techniques do take time, but in reality they are time savers and saviors of the business.

Pay me now during the project or pay me much more later during the business.

Don’t forget to leave your comments below.

Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BPMessentials. He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business. Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – [email protected].

References

(1) Cracking Creativity: The Secrets of Creative Genius by Michael Michalko, 2001
(2) The Day the Earth Stood Still, 20^th Century Studio, 2009
(3) Leading Change by John P. Kotter, 1996

How Much Rework Do You Have?

Written by Tony Higgins on March 29, 2011. Posted in Articles. 1 Comment on How Much Rework Do You Have?

As a requirements solution vendor we talk with people every day about their requirements issues, assist them to understand the root causes, and help them articulate a business case for investing in a solution. For most companies, the biggest single inefficiency in their software development efforts is the amount of rework that’s done due to inadequate requirements. (The reasons as to why the requirements are inadequate are many and beyond this post but stay tuned for a new paper on the topic that goes into more depth).

When we ask people how much rework they have done on their software projects, the answer varies consistently between 5% and 25%. I find this fascinating since industry statistics show the average rework rate to be considerably higher (Forrester: 30%; voke: 40%). Why do people regularly report lower rework rates? Here are some reasons based on these conversations:

Vocabulary

On many projects, rework is simply known by a different name. In many cases it appears as contingency or padding in other line items within the budgeting process. In others a large amount of rework is pushed in to maintenance, and in extreme cases a new project may even be positioned.

Awareness

We have had countless conversations where people were simply unaware that rework happened. One reason is related to the vocabulary mentioned above where the rework may be disguised and dispersed under different budget items hiding the true nature of this expenditure as rework.

Scope

It seems that most people only consider the rework that takes place in the development aspect of a project. The total cost of rework depends on many factors including your development process and where you may be in the development cycle, but should include all impacted areas as well, such as: planning & estimating; all forms of testing (unit test, integration testing, regression testing, etc.); product documentation; user support; services and training; etc. When all these are factored in, the true magnitude of rework becomes much clearer.

Denial

Rework implies that something was done wrong, requiring work to be repeated. Nobody likes to be associated with this and for many it is difficult to come to terms with the amount of rework that actually takes place on the average software project. While initial discussion may start with the claim of minimal rework, after a little inquiry the rate tends to creep up. I recall one time in particular where the initial rate of 7% rework ended up being 35% after our conversation.

Combinations of the above

Various combinations of the above may be at work, each contributing to the low rework numbers that people report, and may actually believe, on a regular basis.

I wouldn’t be surprised if there are more reasons and would love to hear any you’re aware of. As people realize the true magnitude of rework on software projects, it quickly becomes a prime target for improvement initiatives.

Don’t forget to leave your comments below.

Tony Higgins is Vice-Presidentof Product Marketing for Blueprint, the leading provider of requirements definition solutions for the business analyst. Named a “Cool Vendor” in Application Development by leading analyst firm Gartner, and the winner of the Jolt Excellence Award in Design and Modeling, Blueprint aligns business and IT teams by delivering the industry’s leading requirements suite designed specifically for the business analyst.