Tag: Requirements

Managing Requirements: Can ITIL help?

Written by Terry Longo on April 14, 2008. Posted in Articles.

Over the last six months I have presented to numerous audiences on the topic of how Business Analysis and IT Service Management (based on ITIL) can work together, indeed must work together, to drive the level of quality and cost-effectiveness we are all seeking within the IT solutions space.

Interestingly, there has been a notable difference in the nature of the feedback

PM/BA audiences (such as those at the Project Summit / BA World events) have provided fairly positive feedback (and in fact the trend is upward over time)
ITIL knowledgeable/experienced audience feedback has been overwhelmingly positive, to the point where they are asking to have the presentation brought to their own organizations!

I am predicting that over time, as BAs look for additional ways to strengthen the rigor of their business cases, they will increasingly rely on the IT organization’s use of ITIL as a basis for defining and driving fundamental BA/IT interactions, including change management and financial characterization of solution development, deployment, and operation.

If you are a BA, do you work within or with an ITIL-based IT organization? If so, can you identify specific benefits that have emerged from the IT organization taking the ITIL path?

Terry Longo has more than 25 years of IT experience, including software development, system and network administration, and instructing, as well as being responsible for the requirements, project management, and delivery aspects of complex training solutions. He currently holds the IT Service Manager ITIL and is responsible for HP Education’s ITIL, Project Management and Business Analysis curriculums in the US. Terry can be reached through http://www.hp.com/education/sections/pm_bus_analy.html or at [email protected]

Enterprise Requirements Alignment: The Top Three Challenges

Written by Terry Longo on March 31, 2008. Posted in Articles.

1. Change Management as an enterprise core competency. Consider any particular requirement. At any point in time, one of the following is true:

The requirement is valid but not being met – in which case some aspect of the solution must be changed.
The requirement is not valid (even if it used to be) – subjecting it to further iterations of the requirements life cycle and corresponding changes to the underlying solution
The requirement is being met and will remain valid for the foreseeable future – in which case attention will turn to changes to the solution for increased efficiencies. (This means, by the way, that even the “as is” operational elements of an enterprise are as subject to change as the transformational elements.
In other words, if the requirement is not being met, change is necessary. And if the requirement is being met, change is necessary. Earlier posts to this blog have said plenty about the position that everyone in an enterprise is carrying out requirements management within their respective domains. But what is requirements management but a specific form of change management?

2. Financial Fluency as an enterprise core competency. It is easy to construe scenarios in which the failure of even a single small-scope technical component of an IT based business solution can totally eliminate the solution’s business case. That means that senior management’s view of the solution’s status throughout the life cycle would ideally assimilate the status of that component, requiring the component’s owner to be able to express status in senior management terms of cost, risks, and trend. In other words, each contributor to a solution needs to be financially fluent within his or her domain. And, every time a change must be accommodated, contributors to the solution must reflect how that change impacts the financial picture for their own contributions.

3. The Business Analysis Center of Excellence (BACOE). Enterprise-wide consistency in managing changes to requirements and solutions, along with consistency in measuring, monitoring, and status reporting across, up and down the enterprise requirements hierarchy, demands an enterprise-level entity. This would serve to define and drive the implementation and continuous improvement of best practices in change management and financial management.

You might notice that I have not included in the top three the selection of a tool to underpin enterprise-wide change, requirements, and financial management. Tools are easy. The real challenge is driving the enterprise culture to the point where an understanding of one’s job in terms of requirements management, change management, and financial management is second nature.

Alignment, Requirements, CBAP and MORE!!

Written by Cynthia Low on March 14, 2008. Posted in Articles.

Great line-up of articles and blogs for this issue! From proper language of alignment to CBAP Soup to Nuts and everything in between, including a Letter from the IIBA President in the IIBA Insight section. I know that you’ll really enjoy this issue’s content.

I want to personally thank not only YOU, our subscriber, but all of our content contributors. We truly appreciate your insight, thoughts and overall contribution. Now – I’ve got one request to YOU – let’s here your feedback.

We have had a few suggestions to our new suggestion box, which we have quickly acted upon. Please utilize this new opportunity for you to offer ways to improve the site, suggest content, or offer new discussions forums you think we should add. We can not continue to improve without hearing from you so keep the suggestions flying!

Stay tuned for our 1 year anniversary celebration! Happy reading!

Best Regards,

Adam R. Kahn

The Language of Alignment

Written by Terry Longo on March 14, 2008. Posted in Articles.

Business benefit, growth, and profitability. Cost and risk. Value add. Forecast confidence. Customer satisfaction and loyalty. These are the measures of senior management. And if the goal of a commercial enterprise is to make money now and in the future, everyone in the enterprise needs to be behind that goal.

You manage a business unit and are looking at a red/amber/green dashboard report of your current programs, and you see that one is red. With your browser, you drill down the trail of red, each click bringing you to a lower level dashboard with more detail about a specific aspect of the at-risk program. Here is what you find:

The business’s success with a new product line is at risk because
The sales teams might not be prepared to sell the new product line because
Sales training for the new product line may be delayed because
Implementation of the Learning Management System (LMS) may be delayed because
The LMS module used for the management of training records may be delayed because
Development of the core code library for that module may be delayed because
The lead developer may need to leave the project due to an important and urgent personal matter

While the above may seem dreamy, it’s where we’re headed. Everybody in a value supply chain, from the lead developer to the LMS implementation project lead, to the sales team manager, to the business unit manager should, at any point in time, be able to express the status of his or her responsibilities in terms of Cost, Risk and Business Benefit.

The costs, risks, and benefits of what, you may ask? Simply put, for each person or team in the value supply chain, the costs, risks, and benefits of meeting their requirements.

Previously I have argued that the requirements management activities of planning, eliciting, etc. are necessary regardless of the domain in which one is working (instructional design, business strategy, database design, etc.). It is not only possible, but necessary, that requirements managers in those domains be able to express their status in terms of cost, risk, and business benefit. Rolling up requirements status to a senior level necessitates a common language, and that language is defined by the top-level requirement(s) of the enterprise.

We have much to do. In my next post, we will elaborate on the above and identify the top three challenges in achieving the dream.

Do you have any thoughts or questions about this post and earlier posts? Please don’t be shy! Let us know what you’re thinking by adding a comment below.

or at [email protected]

Never Let a Good Editor Go

Written by Cynthia Low on March 14, 2008. Posted in Articles. 1 Comment on Never Let a Good Editor Go

When documenting systems, quality assurance requires quality support people, especially final content editors. They are worth their weight in gold-edged certificates. If you are part of a large project that has a very large documentation aspect, learn to nurture, develop, and retain a good editorial staff, and do not forget to keep everyone’s skills current on the tools you are using! The current crop of word processor and presentation software packages are constantly adding features to make your life easier.

In our ever more technical world, documentation is still one of the most important aspects. Everyone likes to “feel the weight” of what they accomplished, and documentation is commonly a major part of closure in a project.

The Second Eye
If you have ever had to write a program or a document that was 2000 pages or longer, you will probably get to the point of forgetting what you wrote days, weeks, or months ago. I know I do. That is where a good editor can save the day. Make it a habit of passing along the content in reasonably sized pieces to another soul who dutifully reads every line, checks every drawing for accuracy, and checks syntax and examples. This is a truly wonderful thing.

A second set of eyes will see things that you cannot. Spelling, grammar, syntax, run on sentences, redundancy, too much or too little detail, irrelevant details, your own quirky tidbits that might not be as clear to them as to you, the list is endless … and the work is absolutely crucial!

Praise Your Editor
Thank them for finding those errors that you were unable to see after looking at the same page for hours. Most modern word processors can handle spelling errors but not if they are technical jargon or corporate jargon.

I like to break my content into smaller, specific pieces if possible, but this does depend on the client requirements. If the programs are small, then the sections can be small and succinct. In some cases, the sections require previous sections to be completed and functioning. Only someone who was totally familiar with the whole picture, the end product, and the inter-relationships of the pieces can provide you with a good set of eyes to review your content with.

Send them praises: Excellent work finding “the the”, “good idea to add that as well”, “you are once again correct, that part is unnecessary”. “good eye, I forgot that topic entirely”…

Editing is an Art
Being an editor requires a great depth and breadth of knowledge on the subject. I would not pass this document on to my teenage daughter; it would be gibberish. She once asked me to “fix” her paragraphs about the Crusades. I expounded on them and thought I was keeping it simple. Alas, I was way too technical. I added about 10 extra words for every two of hers. Then there are many times when I edit her words to be, shall we say, more accurate.

On some recent technical documents, I was doing the developing and passing it on to three evil editors. The first two were masochistic, butchering the youngling without regard for effect, it seemed. They passed it to the third editor, a very technical person, who must have thought I was completely incompetent when he got the butchered remains of my work. It was an interesting few months of trying to figure out their system. And, interestingly enough, that last technical editor was actually very competent. He never missed a detail, was very thorough and fortunately knew his stuff. The other two butchers were trying to fit the content into a web page design rather than have the web page provide the content.

Editing Adds Time
It is highly likely that your editor is not doing this full time for you. Hence, you need to allow for their scheduling requirements within your schedule. Having lots of lag time is always nice. Giving them clearly stated times and dates for delivery of their edits are other important aspects. Everything takes time, and time gets consumed faster the closer the project deadline is.

When I line up an editor, I make it clear there is some flexibility in their timelines at the beginning especially and I try to ensure that deadlines do not force me, or them, to cut corners. Deadlines really are annoying at times! I also make it very clear what the deadlines are and how they can help me meet them, along with general ideas of what I want them to look for, and how they should send change requests or make adjustments.

Give Them Source or Don’t Give Them Source?
This can be a tricky issue. Should you give your editor the source and let them make changes directly to the document? Yes and no.

If you can have tracking of changes, this is always an excellent idea. What if they change your source document without tracking the changes? If you are working with a competent editor to whom you have given this option and in whose inputs you trust, then this is one way to get it done faster. You should, of course, edit their changes for them!

In some cases, as the editor, you may not get the source code, or as the owner of the document, you may not want to give them the source. In some of my recent projects, I would get a PDF of the document. This was fine for simple grammar and syntax errors but became onerous when major changes were required. I was forced to send in “sticky notes” of changes. This is probably the least efficient method for the editor, but it does maintain total control by the owner of the document. There are probably a lot of good and bad reasons for using this method, I just cannot think of any good ones.

Being an editor is important and can be rewarding. Having a bad system for rendering changes will ruin the relationship. A good project management truism is to retain your best support people, and especially a good editor. They make your project that much easier to complete on time.

David Egan, RHCE, PMP,

is an instructor with Global Knowledge Training LLC. This article was originally published in Global Knowledge’s Management in Motion e-newsletter, named Business Brief. Global Knowledge (www.globalknowledge.com) delivers comprehensive hands-on project management, business analysis, ITIL, and professional skills training. Visit our online Knowledge Center for free white papers, webinars, and more.