Requirement Gathering

Requirements gathering can be challenging at times. Sometimes discussions just go of tangent. Here are a few of the things I have found helpful.

Pre-requirement Gathering - Prior to engaging users for requirement gathering sessions:

1. Overview of the solution that they're looking at - applicable if you're pitching a solution and are gathering requirements for it. Give a good overview of what it is capable of and as much as possible, relate to generic challenges faced by most organisations.
2. Give out an agenda, describing what the requirement gathering sessions are for, how long it will take, any preparation that might be required (current processes, forms, etc.).

Requirement Gathering Agenda - When conducting a session, I find that this is a good guideline:

1. Introduction - Get the users to give an overview of the company (if you haven't already) and where they fit into the organisation, what their department/business unit does and what their role is within that.
2. Current state – what their day to day activity might look like, what are the things/processes that they are/business unit is involved in. Sometimes you get some valuable information or can derive certain things, i.e. users are disciplined, quick to learn, tech savy, etc. Not everything that they're doing today is evil or bad! Somethings may require minor tweaks, others revamp/overhaul.
3. Current problems/issues faced with the lack of process/systems - favourite time where you listen to all the challenges, be careful not to go into solution mode (both you and the user). Just document the issues and problems.
4. Requirements - What they want in the solution. Gather both functional and non-functional requirements. Try to ensure that users can distinct between 'must haves' and 'nice to haves'. Always validate with users.
5. Wrap it up - let them know what the next steps are. Whether it'd be a follow on workshop, deliverable document, follow up calls to validate items.

Some of the items here have been incorporated from the Microsoft BVPS engagement model.

MOSS 2007 Beta Experience

I've been wanting to post about my experience in implementing and deploying MOSS 2007 Beta. This wasn't the easiest of things to do really. Today, that implementation has gone out as successfuly case study and we're looking into deploying MOSS 2007 for production in the near future.

10 of the valuable things I've learnt while implementing MOSS 2007 software in the beta stage and this could be quite a standard thing with most beta products (Microsoft Office 14?):

1. We definately need to set the users expectations right and let them know of the risks that are involved in deploying and implementing a beta software.
2. It's a learning curve for all parties involved and time spent on certain things which would normally take less time could take more than expected.
3. The users will need to identify certain areas they are keen to explore and try to focus on a particular area so that there is value at the end of the implementation.
4. I believe it's not so much a best practice or optimizing performance but trying to get a certain concept or idea correct at this stage.
5. Very important is to foster a close relationship with the client and keeping them updated on what's going on even of the bugs and faults the software is causing. Some of them love seeing this!
6. Keeping up to date with the beta newsgroups, blogs and other sources of information do help.
7. Lots and lots of testing and finding alternative ways and methods to achieve the same end result!
8. Using the software in it's beta stage for some aspect of the project (used it as repository for project documents) helped the users get familiar and helped the team learn! Of course we also kept the documents in some other repository just in case.
9. We musn't be afraid to break the software as it's in it's beta stage and we need to discover the "breakability" of it so that we can;
10. Report bugs!

Those were some of things I've learnt and I believe the most annoying thing was when the software wasn't behaving as it was suppose to it was always a matter of... "was the software mucking up because it's in beta or was I mucking up that the software wasn't doing what it was suppose to..."

It was a good experience at the end of the day!

be a friend to your customer

Of recent when working with clients I've realized to focus on customer relationship building where the process begins with having an emotional (in a good way) element when you establish a connection with your clients.

So what is good relationship building?
Developing and maintaining a win-win partnership where both parties gain, is the essence of a good customer or client relationship. When you have a good and trustworthy relationship with your clients, you're on the path to growth and profitability. Why do I say that? Well, your customer serves as an important reference for new prospects. Their happiness and level of satisfaction serves as a marketing tool (I've seen this happen). Also, the time taken to attract a new client is shortened which might lead to lower costs for repeat business.

The ability to build good customer relationships depends on three things:

• product knowledge
• people skills; and
• your attitude

Building the relationship
To engage a customer, you need to have good product knowledge, so read all the material you can possibly get on your product, and I think using it is definately a plus! By having the right information and tools on the product, you will feel empowered to handle most questions.

Your soft skills or people skills, and your positive attidude help you in connecting with the customer. Show your sincerity in identifying what your customers value.

I hear this term quite often where "listen to your customer as opposed to merely hearing him". Where you seek to understand them from their frame of reference. Listen carefully to what they say and notice hints they about their interest.

Maintaining the relationship
To maintain good customer relationship, we need to store some data on customers' interest in order to target them selectively. I also believe that simple gestures like sending a greeting card or a thank you card do help strengthen the relationship. Also attending to their complains and attending to them punctually also do help.

Measuring Customer Readiness for EPM

You can gage the customers readiness in adopting EPM by asking some fundamental questions:

• Does the customer know the benefits to be gained from an EPM Solution?
• Does the customer have some preliminary goals and objectives for EPM?
• Does the customer understand what EPM is and its core capabilities?
• Does the customer know the EPM capabilities currently in place in the organization?

You would then want to determine the customers Project Management Maturity.

Business problems that a document management system can address

1. It is taking me too long to find critical business information.
2. It is costing me too much to handle paper (e.g. storage, archiving, courier, fax, photo copies, loss of information, natural disasters).
3. I can't track and manage my document-based business processes.
4. File servers and email servers are growing at an alarming rate thus making it hard to manage.
5. I need to secure my documents!
6. I need audit capability (e.g. SOX).

EPM Best Practices

Excellent article. Worth the read!

http://www.clsassociates.com/EPMBestPracs.pdf

Document Concerns

Some of the concerns organizations might have regarding their document. Probably some key areas to focus on and analyse. How, when and by whom your documents are accessed?

Confidentiality - Control who has access to the document.

Authorization - Control what someone can do with the document.

Accountability - Track what someone does with the document.

Integrity - Show whether a document has been altered.

Authenticity - Verify the source of the document.

Keys to a Successful ECM Solution

An ECM solution could be the answer to your organizational needs in terms of archiving, auditing and collaborating but there are challenges that hinder a successful ECM solution rollout.

User acceptance is very important as the ECM solution is for the end user. They need to buy into the idea, therefore the ECM needs to be something simple for them. The ECM is to improve the way they work and to help with their daily tasks and shouldn't burden them even further. The learning curve and training should also be very minimal. User acceptance will be fastest if users actually recognize the ECM solution as making their personal work life more efficient and streamlined.

Unified solution will tip the scale on the success of the ECM solution. The ECM solution should provide for many of the functionalities that are required within the requirement. Most of the time multiple applications which are not standardized put the users off. The organization will definately have diversified needs as each departments / individuals focus could be different but working towards a common goal. Therefore the ECM solution needs to be able to meet these needs with robust and customizable ECM solution.

Users should have the power to manage their own solutions. Therefore this will minimize the involvement and burden of IT on the ECM. This is essential to involve the IT administrators as little as possible as they already have much at hand. The ECM solution needs to cater for different users to be able to manage their own areas. The only involvement of IT is to manage the ECM solution in a centralized manner and the granular details can be handled by users.

Questions for Document Management Analysis

Sometimes I find it hard to actually get a conversation started with clients. So I remember 5 simple and easy questions to help myself gage some of the problems customers face with document management.

1. What are the hardcopy / manual process that are currently in place?
2. In these processes, what are the top 3/4/5 pain issues that you face?
3. How many people are involved and how do they communicate with one another?
4. How are the documents distributed and are there remote locations, what is the cost incurred?
5. Once the process has been completed, what are the plans on storing or preserving the document?

Some questions to get the conversation started and to build a foundation for further analysis.

Components of ECM

Gartner defines 6 core components for an Enterprise Content Management system.

1. Document Management
2. Web Content Management
3. Records Management
4. Document Capture
5. Document Imaging
6. Document Centric Collaboration & Workflow

Ubiquitous Computing

"... many enterprise employees are disconnected from the company information systems for long periods of time. They cannot communicate business-critical information promptly, or react to changing business priorities quickly"

reference: Gartner, 2002

Microsoft Office 2007 suite of products, especially with Groove and SharePoint 2007 we'll see more collaboration and communication between information / knowledge workers.

Solving the ECM Puzzle

Recently I've dived into the world of documents/content which led me to an interest in Enterprise Content Management (ECM) solutions. Through my findings and discovery, a little insight into ECM and if ECM is for you and your organization. five key components of the ECM.

1. Capture - How would you move documents (hardcopy/softcopy) into the repository for reuse, distribution and storage?
2. Manage - What are the tools and techniques for moving content around an organization and monitoring this tools' performance?
3. Store - Where do you put the content and how'd you find it again?
4. Deliver - How do you get the right content to the right audience on the right device?
5. Preserve - What are the options for long term archival and storage of your company's essential content?

references: AIIM