Articles Archives - Page 366 of 418 - Business Analyst Articles, Webinars, Templates, Jobs

Secret Public BA Shames. Part 3.

Written by Marcos Ferrer on December 15, 2009. Posted in Articles. 1 Comment on Secret Public BA Shames. Part 3.

An executive at a county government agency once called me on the carpet during a short term consulting gig because of a relationship problem.

An employee with a BA title objected to my presence, and cursed at me repeatedly in meetings, questioning my qualifications (CBAP 007, at your service) and belligerently challenging my efforts to build consensus in meetings for BA standards at the agency.

This employee was the dominant personality disorder in a dysfunctional BA environment, and had been cited by numerous people as a point of confusion – there was no consensus around this person’s work, and yet there was no question of changing this person’s work.

I didn’t get called on the carpet until I had an interview with this person’s manager, and pointed out that the ability to lead a consensus for good requirements was essential for the BA position, and that this person did not seem able to do so.

WHAM! I’m called to the principal’s office (not an analogy – keep reading). The executive said to me (I paraphrase) – What do you think you are doing? You are trying to treat these people like adults, and this place is like a high school.

SO. What is the ethical response, when one is on a contract to improve BA process, but the problem with BA process is that everyone is acting like teenagers?

I can hardly wait to hear!

NEXT MONTH another situation. Send yours, if you know of one; all anonymity will be protected!

Have fun, and please send your questions or comments

Don’t forget to leave your comments below

Marcos Ferrer, CBAP has over 20 years experience in the practice of business analysis and the application of Information Technology for process improvement. Following graduation in 1983 from the University of Chicago, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in diverse industries. His recent projects include working requirements for the Veteran’s Administration, introducing BA practices at the Washington Suburban Sanitary Commission, and creating bowling industry models for NRG Bowl LLC. In November 2006, Marcos Ferrer is one of the first CBAPs certified by the IIBA. He has served as an elected member of the DC-Metro chapter of the IIBA, most recently as President, and assisted in the writing of the BOK 2.0 test.

Bad Ass BA; Peer Review. Part 4.

Written by Cecilie Hoffman on December 8, 2009. Posted in Articles.

Co-authored by Rebecca Burgess

Use and Profit from Peer Reviews of Requirements Documents

This is Part 4 of a 4-part series on how to perform a Peer Review of a requirements document.

The four steps in a Requirements Document review are:

Business Case Synchronicity Check
Requirements Document Sanity Check
Requirements Statements Content Check
Requirements Document Housekeeping Check

Remember that these checks are filters, that is, if the document doesn’t pass the Business Case Synchronicity Check, you will stop the review. Only if the document and the business case are in sync, will you check for sanity. Then if the document survives both of those checks, you’ll review the content quality of the requirements statements. In Part 3 we did the heavy lifting, we scrubbed the content of the requirements sparkling clean and we tidied up the categories. We aren’t done yet, we need to put on the white glove and do the housekeeping check. Once the document passes the housekeeping check, it has passed Peer Review and is ready to go to the Customer or the Requirements Review Board, or whatever the last step is in your organization’s requirements review process.

First, a quick recap….

Why Perform Peer Reviews?

Why bother with peer reviews in the first place? Here are a few concise reasons to use this powerful tool:

– Improve the quality of the document being reviewed – More eyes are better.

– Identify and correct project problems, errors, and omissions as early in the project cycle as possible – Early fixes are cheaper, by orders of magnitude.

– Learn from colleagues’ insights and errors – If they can’t be a good example, they can be a horrible warning.

– Broaden your knowledge of other areas of the business – the more you know about the business, the easier it is to move up to that “enterprise analyst” position.

– Ask the stupid questions – see Bad-Ass BA Lessons. Part 2.

What excuses do people use to avoid peer review and how can you counter those excuses? There are many excuses, but these are the most common:

It’s scary! – They won’t say this out loud, but it’s true. You must separate your self esteem from the evaluation of your work by learning to accept criticism as constructive and valued, rather than destructive and to be avoided at all cost.
It takes time – Yes, but the payback is substantial, both in minimizing the impact of errors, and in maturing the BAs on the team.
We are already behind schedule – Would you rather let the customer catch the errors? Or worse yet, miss the errors?
I don’t know anything about that project – So you’ll limit your review to the more general, BA-level comments; that’s still valuable. Also see “Broaden your knowledge” in the reasons to do peer reviews, above.
It’s hard to do – True. And these articles will make it easier, so read on….

Requirements Document Housekeeping Check

Why bother with housekeeping? We’ve been back and forth over this document already and know that the contents are correct, so what if there are a couple of little typos, or a diagram is mislabeled? Unfortunately, this is another example of the first impressions principle; when reviewers see small mistakes, they begin to suspect that there are bigger mistakes hiding in the document. It’s the “spinach in the teeth” problem again.

Create a chart and check off each item if you can answer “yes” for in the document you are reviewing

Part 4. Requirements Document Housekeeping Check

Is the BRD template the “current” template?

Cutting and pasting content from a previous BRD is easy, but it could create problems if the current template has new sections or revised instructions. If the document is perceived to have “missing” sections, that is not okay.

Is the Table of Contents in sync with the document content? Look at both the section headings and the page numbers.

Is the business owner or executive sponsor named as an approver?

If not, should they be?

Are all figures, tables, and diagrams labeled? Is the numbering consecutive?

Are all units of measure defined?

For example, in international companies the default currency needs to be defined, not assumed.

Are terms that may not be familiar to the reader defined?

Take pity on the people who read the requirements document who aren’t domain experts but have a responsibility to ensure the quality of the document. As a peer reviewer, if you don’t know what the term or acronym means, it is your duty to ensure that the term/acronym finds its way into the glossary.

Are all diagrams referenced in the text actually present in the document?

Copy and paste, or copy and edit from other documents isn’t plagiarism, it is “leverage”. Sometimes we forget to make sure that diagrams will be available in this new context.

Is information presented in the most clear and concise format?

Should some text blocks be converted to a bulleted list? Or a table? Should some text blocks be accompanied by a diagram?

For those sections provided by the template that do not apply to this specific project, is there a sentence that says, “This section does not apply to this project.”

Leaving a section blank looks sloppy, as if you forgot something. Removing a section looks like you are hiding something.

Is each requirement uniquely identified?

The unique identifier is needed for traceability.

Does each requirement have a priority?

The PM will want to know what is most important to the Customer. Third party vendors will want to know what is most important to include in their quotes.

If most or all requirements are “high” priority, is there a secondary way to indicate which requirements could be cut or delayed if scope must be trimmed?

Providing this alternate means to analyze the scope isn’t critical for all requirements documents. If you used a criteria-based matrix to determine the priority of the requirements, your PM will love you if you provide a reference in the appendix to that matrix, “just in case”.

Does each requirement have a source (person’s name, organization) and the date that it was added to the document?

If there are questions about a requirement, who will the PM / BA call? Just providing a name isn’t good enough. A year from now, a key stakeholder could easily have moved to a different organization.

Has someone who cares about good grammar and spelling reviewed this document?

We work in an international environment. Most native speakers of English have no appreciation for how difficult it is to learn English grammar and spelling. And even native speakers of English may not be able to write a grammatically correct sentence. Find someone with grey hair and wrinkles who has a real wood red pencil. If you do nothing else, for heaven’s sake use the spelling and grammar checkers in your word-processing application.

Have all duplicate requirements been consolidated into unique requirements?

After the “final” review it is normal to have to remove notes you left for the reviewers, such as, “This requirement was removed because it is a duplicate of Scalability-004.” Producing the “final final” document will vary organization to organization. For some groups, you maintain history by presenting the document with the duplicates still in place and enumerated, but called out as duplicates. Other organizations won’t give their approval unless the document is presented in a “clean” form, where you have removed the duplicates and renumbered the requirements so that the document is a clean starting point for the Design team. If you aren’t sure what your organization expects, ask.

If any requirements refer to standards or policies, is the documentation of the policy or standard referenced?

You may need to provide hyperlinks to internal or external documents or websites.

Do all hyperlinks work?

Follow the links – they may work for the BA author but if they don’t work for you, then the links may not work for other people.

Has information that is not relevant to the requirements been separated from requirements, e.g., into an appendix, or put into a separate document?

A requirements review is supposed to be a review of requirements, only, but related topics often seem important and distract people’s attention from the requirements. Examples abound:

Roles and Responsibilities: Who is going to do what? In large companies both Product Engineering and IT will be doing development work. In an outsourced model, development may be done by a third party working in conjunction with an internal customer. This information belongs in an appendix, not in the main body of the BRD.
Project Management: It is not uncommon to see project check points articulated as requirements, but these requirements need to be kept separate from functional and non-functional requirements so that the evaluation of the requested functionality can focus on meeting the overall business needs rather than on the short term project needs and constraints.
Project Delivery: Some requirements documents are maintained as the project moves through project delivery stages, such as Phase 1 and Phase 2. For Phase 3, the “old” requirements from Phase 1 and Phase 2 that have been met need to move from the Requirements section of the document to an Appendix.

If one or more of these items is not checked, there is some risk that these errors or the lack of document organization will taint the perceived quality of the document as a deliverable and possibly cast doubt on the quality of the requirements themselves. Just because the white glove test came back with some lint is no reason to lose heart. Your document is so close to being done that you can taste it. And the truth is that you may be so sick of the document that if you never saw it again you wouldn’t miss it. So, what does a Bad-Ass BA do? Think about what you need. Time away from the document? Just two days away from the document can refresh your eyes and your attitude. Help with grammar? Find that person who reminds you of your high school English teacher and ask for a favor. Remember, Bad-Ass BAs set their egos aside to get the job done. You can do this.

If the answer to all of these questions is yes, then your document has not been carelessly rubber stamped, it has completed a true objective peer review. Is your heart filling with pride? Good. Each time one of your peers found something, did you feel embarrassment? Don’t beat yourself up; just fix the problem, learn from it, and let it go. Do you feel like standing outside in the sunshine for “just a moment”? Good, go do it. If nothing else, do take a moment to breathe before you send the document on to the next step in approval process.

So, is a peer review an easy task? No, it is a painstaking effort and one that I hope will bring you a great deal of personal satisfaction and pride. Each time you bring a document through peer review, think about what you have learned, and find a way to share your new knowledge and confidence with your peers. We are all in this together.

Use and Profit from Peer Reviews on Requirements Documents

Business Case Synchronicity Check
Requirements Document Sanity Check
Requirements Statements Content Check
Requirements Document Housekeeping Check

Make a date to join Cecilie Hoffman for the Bad Ass BA Peer Review Webinar on January 14, 2010. Click here for time and other details.

Don’t forget to leave your comments below

Cecilie Hoffman is a Senior Principal IT Business Analyst in the Business Analysis Center of Excellence, Symantec Services Group, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion, motorcycle riding, at balsamfir.com. She can be reached at [email protected].

Rebecca Burgess is the Business Process Methodology Analyst in the Commerce Lifecycle Transformation Office at Symantec and a Certified Six Sigma Black Belt. After many years of uncovering problems and determining root causes in software, she is now applying her BA skills to strategic process design and improvement. She can be reached at [email protected].

Going Rogue: A Business Analyst Life

Written by Kupe Kupersmith on December 8, 2009. Posted in Articles.

As business analysts, we should have a goal to be perceived as though we are going rogue.

At The Free Dictionary there are plenty of negative definitions of the word rogue. The definition I use for a Rogue BA is the following: Operating outside normal or desirable controls. At the most senior levels we need to look at every situation and do what is necessary for the success of that project. We should not be following a step-by-step process or take the same approach on every project. Every project is different, therefore we need to assess the project and determine our approach based on that assessment. This is why I believe so strongly in the need to dedicate the necessary time on a business analysis work plan prior to starting down the path of the analysis effort. Check out this short webcast on Developing a Business Analysis Work Plan to understand where I am coming from.

Side note: Just in case you were wondering, this post does not in any way represent my views of Sarah Palin. I do thank her for the inspiration in creating the title.

Over the years I have watched companies struggle with determining the right level of flexibility in their business analysis methodology or approach. A thought I have been playing with is that the methodology/approach needs to have the proper amount of rigor for the individual executing the methodology. For example, new and junior BAs struggle if they are left alone to try and assess the project needs and adapt their approach. They will fail miserably with a flexible process. The new and junior BAs do not have the right level of training and/or experience to adapt. How can you bend the rules, if you don’t even know the rules yet? Without the knowledge and experience they don’t have enough stories and history of why certain tools and techniques work for certain situations, while others don’t. They need a mentor and a step-by step process to follow.

At lunch a few weeks ago with my friend Jeff Hyatt, he introduced me to a concept that helps illustrate my thought. It is called ShuHaRi, which he heard about through Alistair Cockburn. ShuHaRi is a Japanese martial arts concept, and describes the stages of learning to mastery. You can read more about how Alistair has written about it here.

In short the idea is that a person passes through three stages of gaining knowledge.

Shu (obey). In this beginning stage, the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.

Ha (digress). At this point the student begins to branch out. With the basic practices working, he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.

Ri (separate). Now the student isn’t learning from other people, but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.

Based on this concept, organizations need a methodology or approach that is flexible enough to work and properly support their BAs in all three stages of learning.

Here is a simple application of this concept to levels of BAs.

New and junior BAs need a prescribed approach with the help of a master.
Intermediate BAs need the support of a community.
Master BAs need to be set free on their project and teach the new, junior, and intermediate BAs.

Many organizations seem to have methodologies and organizational structures that address one of the above, but not all. I have seen organizations that jump right to Ri and set all of their BAs free where many need a step-by-step process. These organizations do not have mentor programs or promote collaboration amongst their BA community. Other organizations have such a rigid process which suits the new and junior BAs, but hinder the more senior BAs.

What stage are you in? Is your organization structured to support all levels of BAs? I challenge you to think about what stage of learning you are in and continue to work on reaching the goal of being perceived as a Rogue BA.

Yours in going rogue,

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected].

Reinventing the Program or Project Portfolio Chart

Written by Mark Jenkins on December 1, 2009. Posted in Articles.

The fourth and final part of my “Reinventing…” series (which ran in Business Analyst Times earlier this year; see links at end of article) concentrates on a project portfolio rollup chart. Since this charting technique also includes and tracks business priority, I call this communication tool the “Project Barometer”.

As with the previous articles, the chart attempts to maximize the amount of information a single diagram can communicate, without overwhelming the reader. However, unlike the previous techniques, which required the use of Visio, the barometer takes advantage of the simplicity of Excel.

For a BA who is actively involved in managing an IT to business relationship, questions regarding project status and upcoming effort are common. I use updates from my team as well as updates from other groups to collate a chart that helps to quickly respond to such prompts as, “What are you guys working on?” or “What is the priority of this project?” by providing relevant information at-a-glance. The aim is not to provide a detailed breakdown of the status of each project; that is better left to your project management team, but to use the Barometer as a communication tool to assist a stakeholders understanding of your IT program at a macro level.

The development of upcoming priorities is also something the barometer tracks effectively; my BA team is also tasked with managing the upcoming IT workload, forming a demand queue through turning stakeholder ideas into project proposals. As such, we use the Project Barometer to help prioritize these stakeholders’ ideas, which we then communicate to the IT management.

Lending a greater level of visibility before a project gets off the ground, the Project Barometer helps individual departments to align themselves with and keep focus on current efforts.

A key part of the BA role is to pinpoint areas of project neglect (areas where a project may have missed stakeholders or scope, downstream impact, etc.). This tool has proved extremely valuable, both in department reviews and, in a more proactive sense, for stakeholders or departments to view at will. I have also found this technique equally appealing to executives and individual contributors for the facile communication and information transfer it procures. Without the Project Barometer chart, our BA team would not be as effective.

When designing this chart, I thought about some of the common problems faced by IT employees, managers and business stakeholders. Typically, project status updates take the form of multiple page documents, PowerPoint presentations and/or meetings to deliver this information, which can be difficult to navigate and time consuming. Although highly detailed reports serve a valuable purpose, the Project Barometer extracts relevant information from those reports and organizes it in a simple, unambiguous chart made accessible to all involved parties. As response to questions regarding status, priority, and effort, the Project Barometer provides immediate information in a concise, visual manner. Such an at-a-glance informational tool becomes ever more important the higher up the corporate ladder you go.

With those parameters in mind, I wanted to find a way to fit an entire program status on a single page. The Project Barometer is a result of these efforts.

View Larger

My barometer consists of 11 columns, which, in order from left to right, track priority, project name, project status, effort and the stages of the SDLC.

The rows are filled with the individual projects grouped together by department. The Sales and Marketing groups are shown here, each separated by the blue bars.

Within each cell, a coding scheme is used to communicate relevant information, I include a legend at the bottom of the barometer but, for the most part, it is self explanatory.

View Larger

In this next part of the article, I’ll provide a step by step guide to building your own barometer.

The easiest way to begin is to list all of your projects currently in progress. For each project, think about the amount of effort involved and which group owns which project. The grouping of projects by department is one of the things that make the barometer useful.

At the end of this effort you should have a list of projects, grouped by department and assessed for effort, such as the example below.

The next step is to think about the stages you track in your SDLC, typically it will be something like the completed barometer shown above, but because Excel is so easy to use, you can adjust the columns as required.

View Larger

It is now a simple exercise to add either the date the stage was completed or the percentage of completed progress to the individual cells.

View Larger

It would be reasonable to stop here and have a functional chart, but as we saw above, there is more information we can communicate. In order to make the chart easier to read, I grouped the projects together by department. To do this I simply merge a row of cells and then, for each section, add and repeat the headers. Moreover, I add the key stakeholder for each department; this is the person you would work with to set the priority of each project.

View Larger

To communicate a clearer idea of progress, we can apply colors to the stages. We’ll follow the standard traffic light format, green for good, amber for minor issues, red for major issues. If a stage has been completed, I always set it to green.

View Larger

During my barometer design, at this point I didn’t feel like the chart was providing as clear a picture as possible because I had all the stage progresses annotated the same way. It makes it hard to differentiate, at-a-glance, between completed and in-progress efforts. To eliminate this problem, when a stage is completed, I change the text color to a light green. This has the effect of making the white, in progress stage, stand out more. As you progress to making larger barometers with a greater number of projects, this effect will become more vivid.

View Larger

We now have a completed diagram mapping the current program status, but what about priority? What about upcoming ideas? As I demonstrated above, this can be built into the same diagram with minimal effort. To tackle priority, I simply add two columns, one labeled “Priority” which tracks position (position one should be the most important project to the stakeholder), and the second column labeled “Movement,” tracking any priority changes. The addition of these two columns makes the barometer a great negotiation tool. Combining the Project Barometer with the Resource Chart forms a powerful arsenal of persuasion, with the odds stacked in your favor.

Dealing with the practicality of keeping the chart current, if a project is added with a higher priority than existing efforts have or a project priority is downgraded, I generally only show the movement of the added or downgraded project (i.e., I don’t show the shift in movement through the list of each of the others).

View Larger

Adding and prioritizing upcoming ideas or requests is also easily facilitated. Add an extra column for status, add the ideas and then update as needed. You could also track any kind of status here. You may have a designation for small projects and large projects, for example.

View Larger

The diagram is now nearly complete, once the version and date range are added. I typically update at least three times a week.

In summary, we have again created a simple but highly readable diagram to demonstrate the current status of projects and ideas, and in so doing, provide a complete picture of the program.

I’ve received some positive feedback on this series of articles, so thank you for taking the time to read and reply with your comments. In the majority of emails, I receive requests for a template. Now that I have finished the series, I’m working on bundling the templates and stencils into something you can all download.

http://www.batimes.com/component/content/article/106-articles/453-reinventing-the-swim-lane-diagram-part-1.html

http://www.batimes.com/component/content/article/106-articles/463-reinventing-the-swim-lane-diagram-part-2.html

http://www.batimes.com/articles/106-articles/490-reinventing-the-resource-chart.html

Don’t forget to leave your comments below

Mark Jenkins is Manager Business Analysis Group at Websense. Mark has spent the last year establishing this formal business analysis group that now plays an active role in all major business projects at Websense. As part of the development, he created new process and documentation standards, which assisted in the overhaul of IT Project processes, placing the BA Group at the forefront of the IT to business interactions. He can be reached at [email protected] and on twitter www.twitter.com/JenkoUK

Four Trips to Midnight

Written by Keith Ellis on December 1, 2009. Posted in Articles. 1 Comment on Four Trips to Midnight

Midnight is a dark time, like a looming deadline which you’re pretty sure you can’t meet. No one is ever sure exactly how they got into the position of running up against midnight, but it usually means long hours late at night – and lots of caffeine. Perhaps it also includes a dose of wistful thinking and wondering about the project plan that seems to be growing like David Banner in a snit. Sometimes it happens, the work load just got misjudged, or the magic of juggling priorities and fate landed a few choice lemons in your lap. Maybe it’s a different problem altogether.

I’ve noticed lots of analysts have trouble with estimating the amount of time it will take to complete business analysis and the elicitation and documentation of requirements for a project. I remember evaluating a team where the most forgiving management stakeholder I interviewed stated they were currently at 300% of the expected time needed to get requirements – and that was just her personal time… not elapsed time (which was months over schedule). Estimating analyst effort is tough because business analysis is inherently about taking a concept that is airy-fairy-fluffy, and turning it into something that is concrete-with-dimension. Here are some ideas to think about late at night – hopefully some of these will prevent you from burning the midnight oil on your next project.

Your company might be lousy at scoping… It’s crazy the number of companies that don’t stick a little micro-engagement on the front end of their analyst work effort. The only purpose of the engagement is to figure out how long (with reasonable precision) it will take to do requirements, and to figure out the plan to get these requirements done. Sound silly – a plan to do the plan? On the contrary, it will likely end up as the highest value you offer as an analyst organization. Remember, many companies also spin for months on very early stage projects with little to show for it – this micro-engagement will break that spin cycle. The other added bonus is that high quality requirements plans keep stakeholders engaged, and that makes it more efficient for everyone.
Your company might have ambiguously defined process and outputs… This situation is like trying to shoot a bulls-eye while riding a mad bronco while shooting at a bouncing target. Hitting it ain’t going to happen! In my early years, I once had an executive say at the end of an engagement, “can you get some more business context into those requirements?” I said, “we’ve already documented the process flow, data flow, business rules, for every process in the business and used these as the basis for the business requirements, I also have a context diagram, business objectives, and good representation of the issues and interdependencies. What’s missing?” I guess he figured I had his funding plan all figured out too. Get some precision on the expected outcome and what that means before you start committing on timelines.
Lousy practices (ouch!)? OK, so this shouldn’t be rocket science, but you might want to try breaking analysis down into Use Cases, Business Events, User Stories, or some other collectively-inclusive-yet-mutually-exclusive bits of work. Then estimate how many of these you have. Start with the business process areas, how many big processes are we dealing with, how many Use Cases in those processes, etc? Here’s the magic bit… keep track of how long it takes you to do one for you and other members of your team.
Maybe it’s the review process that needs improvement? Some review processes have very little end in sight. Especially ugly is the organization that expects to get business signoff on very detailed systems specification with lots of techno-babble. I did some consulting for another company that was big on peer reviewing. Peer reviewing is great, but every reviewer at that particular company did requirements a bit different, so it was driving the analyst teams nuts and creating lots of inefficient rework. It will save you lots of time and effort if you get a clear expectation of level of detail, form, format, and maybe even get agreement from the stakeholders on what a good requirements document looks like before you get underway. At least that way, you can show the reviewers what the agreed upon target looks like – or walk recalcitrant stakeholders and sponsors through the templates that worked so well on that other successful project. Then show them how yours provides the same level of detail, and walk them through the process through which that detail was assembled.

Here’s a secret – only a small minority of companies actually produce requirements plans on projects. Yet many of you end up burning the candle at both ends trying to meet a somewhat arbitrary deadline on the requirements preparation. Don’t stay on a train that will keep taking you to midnight over and over. Step back; it might be time to change the process.

What’s your favorite cause for a trip to midnight?

Don’t forget to leave your comments below

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.