Tag: Requirements

Failing to Plan is Planning to Fail

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

There is a popular adage often attributed to Benjamin Franklin, the father of time management, “Failing to plan is planning to fail,” The quote may sound like music to your ears but planning for business analysis work is a key area which tries to zero in on the importance of planning in a software development project. Sadly, it is a step that is often overlooked.

The absence of proper planning can detrimentally affect timely meeting of the on-going project deliverables. To avoid such a failure it is vital that a project manager ensure that the requirement planning activity is given due importance, so that everything is under complete control.

So, how can a project manager ensure that a business analyst (BA) is given the power of execution to get the things delivered with the required level of quality and within the defined time frames. Let’s examine some of the key pointers essential to effective business analysis planning.

The Planning Stage

The planning stage gives a high level understanding of the intended software product. It gives the project team a pulse of the current systems and processes, while evaluating the existing deficiencies and identifying the key objectives that need to be addressed in the proposed software development activity.

The planning stage also helps the stakeholders identify the risks that may be associated with the project. Over time, the business requirements keep growing in an attempt to enhance the existing functionality. The objective of the planning stage is to make it absolutely clear – working in partnership with the client and the development teams – what full range of functions and content will be addressed.

The Kick-off Meeting

The kick-off meeting is the opening play of the project. It is an ideal occasion for the project team and the client to introduce them selves and set the project expectations and milestones. The meeting should identify the team roles across the entire spectrum of project related activities, in order to ensure that these activities get completed smoothly.

Requirements Tools and Templates

The business analyst analyses, documents, manages and presents the project requirements for review and approval to the client in a comprehensible manner. As part of the planning process, and early in the project, the BA should communicate to the customer the standard templates and requirement management tools they will adhere to, in order to document the requirements specifications.

For projects large in size and complexity, it is important to make use of requirements management tools to manage version change, track requirement status, communicate with stakeholders and reuse the requirements wherever possible.

Define Points of Contact and Escalation Hierarchy

Should there be any queries or concerns regarding any aspect of the planned project activity, it is important to define a clear process to identify the key points of contact in the project engagement with proper escalation mechanism.

The steering committee is responsible for advice on strategic direction, overseeing planning and implementation, resolving open issues, achieving the project deliverables and milestones, and for preparing a weekly project status report giving updated and accurate information as the project progresses.

The Requirements Sign-off: A Project Milestone

It is imperative that every project participant understand what the Requirements Sign-off means, and its associated impact on the project. Clients should not dismiss sign-off as meaningless, but rather consider it as an important project milestone.

Requirements sign-off means a formal agreement with the project stakeholders, stating that the contents of the requirements document, as drafted, are complete to the final projections and that there are no open issues left to be addressed.

Obtaining a requirements sign-off is typically the final task within the framework of Requirements Communication, which is an expression of the output of requirements gathering to all those concerned with the project.

Conclusion

A holistic approach is absolutely essential and indispensable for the success of the project. It takes effort to leverage and climb the ladder of success. The journey is indeed rewarding and also a voyage of discovery.

Nilesh A. Raje is a Sr.Consultant (Functional) with SYSTIME Computer Systems Ltd. SYSTIME (www.SYSTIME.net) is a leading global business provider delivering reliable, high-quality, cost-effective IT solutions and services. Nilesh has extensive experience in Business Analysis. He has a Bachelor’s Degree in Engineering and is also pursuing his Master’s in Business Administration. He has also been published earlier with International Institute of Business Analysis, a leading association in the world of business analysis, as well as in a previous issue of Project Times. In 2007, Nilesh represented his country as “The Youth Icon of India” in Brussels at the First CCS World Youth Forum in the European Parliament. Nilesh can be reached at [email protected].

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]