Understanding Benefits of Agile

September 21, 2010 by · Leave a Comment
Filed under: Business Analyst Books 

“Agile Portfolio Management” by Jochen Krebs – published by Microsoft 2009

So many books concentrate on the intricate details behind running an Agile IT project I however wanted to look at the Strategic benefits Agile brings to the Organization to see how well it would support Six Sigma. Even though the book does not describe using Agile in a Six Sigma environment, anyone that has been in the industry for a while will be able to get a good overview of Agile and using their own knowledge be able to see from this book how the Agile approach to the IT portfolio can interconnect with current best IT portfolio management practices.
For anyone in Management wanting to get a quick understanding of Agile in action, I recommend this book.

Reports – Cheap Approach

September 20, 2010 by · Leave a Comment
Filed under: Excel, Requirements Gathering Tips, ROI 

Reports can be a low ROI (return on investment) and this post discusses ways to make them affordable.

Reports present information. This information can be needed by many different types of people. Where report development costs is when you have expensive developers creating them. Developers should be focused on only providing access to the data required.

Creating a report involves:

  1. Defining Who Needs a Report and Why.
  2. Defining What Data should be on the Report.
  3. Defining What the Report Should Look Like.
  4. Defining How The Report Should be Delivered.

Step 1: Who Needs a Report and Why?

Asking these questions validates the need for the report. If you cannot show why someone needs a report in a measurable way then it is difficult to justify.

Step 2: What Data should be on the Report?

This is where you and the Developer work together. The Developer role is to provide access to the Data that you or the business have identified the Report will need.

Step 3: What the Report Should Look Like?

The Developer should not be engaged for this, instead the business should have access to tools that allow them to create Report Layouts. It could be as simple as Excel or a complete stand alone reporting system like Crystal Reports. By not using the Developer to build the Report Layouts you reduce cost by using cheaper staff to build them.

Step 4: How the Report Should be Delivered?

As for Step 3 the Business needs access to tools that allow them to setup and maintain Delivery of Reports.

By removing the Developer from certain Tasks, costs can be reduced for Report Creation and Maintenance.  This also  increases the business flexibility as they do not have to wait for a Developer Resource to modify Report Layouts or Change Delivery methods.

ROI – Beware of Hidden Features

September 14, 2010 by · Leave a Comment
Filed under: Requirements Gathering Tips, ROI 

An important ROI (Return On Investment) question that must be asked when implementing Process Change at a Company. “Are there any Hidden Features of the solution that may affect my Process Change and thus reduce my ROI?”

Often after initial Project Goals have been identified and a solution proposed some additional feature come along as part of the solution package. If you do not question the value of these additional features by asking “What is the impact?” then you risk your ROI. Additional features should not be implemented without consideration. They may remove Business Functionality that was never meant to be lost.

Here is an extreme example of the point I am making: Imagine that you need a bigger vehicle for your business and this vehicle is currently shared by several drivers. So you find the bigger vehicle at a great price and everything is perfect. However when you go to pick it up the dealer advises you that they have installed the top of the line security on the vehicle. This security allows only one person whose DNA is encoded in it to drive the vehicle. From the salvia left on the coffee cup when you were last there they have encoded it just for you. So now you have lost the ability for other drivers to use that vehicle.

Some of you might claim that is a gap in the requirements and a better job should have been done. The point I am trying to make in an obvious way is that Features not requested can sneak up on you (Not like in the Obvious Example) when a solution is implemented and destroy your business process. So remember to “Beware of Hidden Features”.

Software Requirements Book

September 11, 2010 by · Leave a Comment
Filed under: Business Analyst Books 

“The Software Requirements Memory Jogger”  written by Ellen Gottesdiener.

It is a handy pocket sized (measures 5.5″ x 4.5″ x 1″ inches) book on gathering and writing Business Requirements associated with Software Development. Topics covered are shown below

  • Eliciting The Requirements
  • Analyzing The Requirements
  • Specifying The Requirements
  • Validating The Requirements
  • Managing The Requirements

For the Business Analyst that is new to the game this is a great book and for the experienced Business Analyst it serves as a gentle reminder.

Ignoring The Past will Bite You

September 9, 2010 by · Leave a Comment
Filed under: Requirements Gathering Tips 

A Big Mistake with requirements gathering is to ignore the Past. You need to think how the business got where it is today. What were the decisions made to come up with the current processes.

You are asked to gather requirements on a existing process and it all seems simple. There in front of you is the end result so all you need to do is document the process that creates it and look at ways to improve it. This is where junior Business Analysts slip up. It could have taken years to get to this end result. All you initially see are the refined processes that support today’s end result. You are not seeing the exceptions to the processes that come along once in a blue moon that require change. So imagine if you propose a solution that is rigid and expensive and then a week after implementation the exception occurs. Now how good will your new processes look?

When gathering requirements for an existing process or processes you need to always ask how likely and how often it will change based on past experience and plan accordingly.

Excel Password

September 8, 2010 by · Leave a Comment
Filed under: Excel, Requirements Gathering Tips 

Excel Password how to recover from a spreadsheet.

When gathering requirements on a Spreadsheet protected by an Excel Password you can use the following simple hack to get the Excel Password. This enables you to research the spreadsheet at depth even if the original author is no longer available.

  1. Copy the Excel Spreadsheet (Right click on the spreadsheet, select copy then right click on empty part of screen and click paste).
  2. Change the suffix of the Excel Spreadsheet Copy from .xls to .txt by editing the name.
  3. Okay the warning message that appears when you do this.
  4. Double click on the .txt version of the spreadsheet which should now open in Notepad.
  5. Ctrl F and search for “Password”.
  6. When you find the word “Password” then you have found your  Excel Password.

Please do not use this Excel Password Hack for illegal Purposes.