So You Want To Be a Requirements Analyst?

Highly Recommended Reading - Authored by Karl E. Wiegers, Process Impact, www.processimpact.com 1

Be it explicitly or not, someone always performs the role of requirements analyst on a software project. The official title may be requirements engineer, business analyst, system analyst, product manager, or simply analyst, but someone needs to translate multiple perspectives into a requirements specification and communicate with other stakeholders. Perhaps most importantly, the analyst helps determine the difference between what customers say they want and what they really need—and that’s easier said than done.

The Principal Conduit

The requirements analyst’s primary responsibility is to gather, analyze, document and validate the needs of the project stakeholders. As the principal conduit through which requirements flow between the customer community and the software development team, you’ll play a central role in collecting and disseminating product information, whereas the project manager takes the lead in communicating project information.

Requirements analyst is a project role, not necessarily a job title. One or more dedicated specialists can perform the role, or it may be assigned to any of a number of team members: the project manager, product manager, subject matter expert, developer or even a user. Nevertheless, a talented analyst can make the difference between project success or failure. In his book, Software Cost Estimation with Cocomo II (Prentice Hall PTR, 2000), Barry Boehm notes that seasoned analysts can reduce a project’s required effort by one third compared to similar projects with inexperienced analysts, and projects with highly skilled analysts require half the effort of those using the least capable analysts.

The Analyst’s Tasks

Straddling the gulf between vague customer ideas and the clear specifications that will guide the software team’s work, the analyst must first understand the users’ goals for the new system and then define functional and quality requirements that allow project managers to estimate, developers to design and build, and testers to verify the product. You can download a generic job description for a requirements analyst from http://www.processimpact.com/goodies.shtml. Here are the typical activities that you’ll perform while wearing the analyst’s hat.

Define Business Needs. Your work begins when you help the business sponsor or the product manager define the project’s business requirements. The first question to ask is, “Why are we undertaking this project?” Business requirements include a statement of the organization’s business objectives and the ultimate vision of what the system will be and do. Working with the people who hold this vision, you’ll help them express it by completing a vision and scope document template.

Identify Project Stakeholders and User Classes. The vision and scope document helps you identify the product’s important user classes and other stakeholders. Next, work with the business sponsors to select appropriate representatives for each user class, enlist their participation and negotiate their responsibilities. Write down the contributions that you’d like from your customer collaborators and agree on an appropriate level of participation from each one.

Elicit Requirements. Requirements for a software product don’t just lie around waiting for someone to collect them. A proactive analyst helps users articulate the system capabilities they need to meet their business objectives. Users naturally emphasize the system’s functional requirements, so steer discussions to include quality attributes, performance goals, business rules, external interfaces and constraints. It’s appropriate to challenge assumptions, but don’t try to force-feed users your own beliefs.

Analyze Requirements. Look for derived requirements that are a logical consequence of the customers’ requests, as well as hunting for those implicit requirements that they expect but haven’t verbalized. Spot the vague, weak words that cause ambiguity and confusion. Point out conflicting requirements and areas that need more detail. Specify the functional requirements at a suitable level of detail for the developers who implement them. A website being built incrementally by a small, well-synchronized team can get away with limited requirements documentation, but a complex embedded system to be outsourced to an offshore supplier needs a precise, detailed software requirements specification (SRS).

Write Specifications. Effective requirements development leads to shared understanding and creation of a system that addresses the customer’s problem. You’re responsible for writing well organized specifications that clearly express this shared understanding. Employing standard templates for use cases and the SRS accelerates requirements development by reminding you of topics that you need to discuss with users.

Model the Requirements. You’ll need to determine when it’s helpful to represent requirements with nontextual media, including graphical analysis models, tables, mathematical equations, storyboards and prototypes. Analysis models depict information at a higher level of abstraction than does detailed text. To maximize communication and clarity, draw analysis models according to the conventions of a standard notation such as the Unified Modeling Language.

Lead Validation. You must ensure that the documented requirements satisfy customer needs and that they’re clear, complete, correct, feasible, necessary, traceable, unambiguous, verifiable and so on. Analysts are the central participants in peer reviews of requirements documents. To ensure that requirements are interpreted correctly, you should also review designs, code and test cases based on the requirements specifications.

Facilitate Prioritization. You’ll broker collaboration and negotiation among the various user classes and developers to ensure that the right people make sensible decisions.

Manage Requirements. After establishing the requirements baseline, your focus will shift to managing those requirements and verifying their satisfaction in the product. Storing the requirements in a commercial tool designed for this purpose can help. You’ll want to track the status of individual functional requirements as they progress from inception to verification in the integrated product. Collect traceability information from team members to connect individual requirements to other system elements. This data will aid in managing changes to the baselined requirements within a change control process and tool.

Soft Skills

An effective analyst combines strong communication, facilitation and interpersonal ability with technical and business domain knowledge and the right personality for the job. Patience and a genuine desire to work with people are key success factors. Here are 10 soft skills that you’ll need to succeed.

1. Listening. Active listening involves eliminating distractions, maintaining an attentive posture and eye contact, and restating key points to confirm your understanding. You need to grasp what people are saying and also to read between the lines to detect what they might be hesitant to say.

Learn how your collaborators prefer to communicate and try to avoid imposing your personal filter of understanding on what you hear the customers say. Watch for assumptions that underlie both what you hear from others and your own interpretation.

2. Interviewing and Questioning. Most requirements input comes through discussions, so an analyst must be able to ask the right questions. For example, users naturally focus on the system’s normal, expected behaviors. However, every programmer knows how much code is needed to handle exceptions. Ask questions such as, “What should happen if...?” or “Could ever arise?” so you can determine how the system should handle anticipated exception conditions. With experience, you’ll become skilled in the art of asking questions that

reveal and clarify uncertainties, disagreements, assumptions and unstated expectations. Donald Gause and Gerald Weinberg describe “context-free questions” in Exploring Requirements: Quality Before Design (Dorset House, 1989).

3. Analytical. You’ll need to be able to operate at various levels of abstraction. Sometimes you must drill down from high-level information into details. In other situations, you’ll need to generalize from a specific need that one user described to a set of requirements that pertain to a whole class of users. Critically evaluate the information gathered from multiple sources to reconcile conflicts, separate user wants from needs, and distinguish solution ideas from requirements.

4. Facilitation. Requirements elicitation workshops are a common technique; to succeed, they require a neutral facilitator. You’ll need strong questioning and observational skills to help groups build trust and to improve the sometimes tense relationship between business and information technology staff. In Requirements by Collaboration: Workshops for Defining Needs (Addison-Wesley, 2002), Ellen Gottesdiener provides a wealth of advice for the workshop facilitator.

5. Observation. If you conscientiously watch a user perform his job or put a current application through its paces, you can detect subtleties that the user might not mention and thus expose new areas for requirements discussion.

6. Writing. Your main deliverable will be a written specification for customers, marketing, managers and technical staff; for this task, you need a solid command of the English (or other natural) language. Strive for clarity; avoid ambiguous words and phrasing, grammatical errors and overly idiomatic expressions.

7. Organization. You’ll be faced with a vast array of jumbled information gathered during elicitation and analysis. Structuring all the rapidly changing bits into a coherent whole demands exceptional organizational skills, along with patience and tenacity.

8. Modeling. From the venerable flowchart through structured analysis models (data flow diagrams, entity-relationship diagrams and the like) to contemporary UML notations, diagrammatic tools should be included in every analyst’s kit. Some of these techniques will be useful when communicating with users; others, with developers. You’ll often need to educate other stakeholders on the value of these techniques and how to read them—and you’ll find that these tools are useful ways to represent information even when you’re not discussing a computer system.

9. Interpersonal. You must be able to get people with competing interests to work together, and you should feel comfortable talking with individuals in diverse job functions and at all levels of the organization. You might also need to work with distributed teams whose members are separated by geography, time zones, cultures or native languages.

10. Creativity. The analyst is not merely a scribe who records whatever customers say. In his article, “Eureka! Why Analysts Should Invent Requirements” (IEEE Software, July/Aug. 2002), requirements authority James Robertson suggests that the best analysts propose requirements. Analysts might conceive innovative product capabilities, imagine new markets and business opportunities and think of ways to surprise and delight their customers. A really valuable analyst finds creative ways to satisfy needs that users didn’t even know they had.

Domain, Business and Task Knowledge

Enthusiasm alone won’t take you very far in requirements gathering; breadth of knowledge gained through experience is the only way to hone your ability. Start with a solid understanding of contemporary requirements-engineering techniques and how they fit in various software development lifecycles. Analysts need to know how to thread requirements development and management activities through the entire product lifespan. A sound understanding of project management, risk management and quality engineering can help prevent requirements issues from torpedoing the project. In a commercial setting, you’ll benefit from knowledge of product management concepts and the way enterprise software products are positioned and developed.

Application domain knowledge is a powerful asset for an effective analyst, minimizing miscommunications with users. Analysts who understand the application domain often detect unstated assumptions and implicit requirements. They can also suggest ways that users could improve their business processes. Such analysts sometimes propose valuable functionality that no user thought of. Conversely, they do a better job of detecting gold-plating—that is, excessive or unnecessary functionality—than does someone who’s unfamiliar with the problem domain.

Grown, Not Trained

There’s no standard educational curriculum or job description for a requirements analyst, which is why most come from diverse backgrounds. If you migrate into analysis from a career as a system user, you’ll need to balance your extensive knowledge of the business and work environment with supplemental training in software engineering and how to communicate with your technical counterparts. You’ll also have to work against any tendency to believe your user experience is all-encompassing, to focus excessively on the user interface, or to ignore input from real users of the new product. On the other hand, if you’re a former developer, you’ll need to beef up your understanding of the business domain and guard against lapses into technical thinking and jargon.

Whatever your background, training and mentoring in the soft skills that the best analysts master, such as effective listening, negotiating and facilitating, helps new analysts of all stripes uncover users’ unspoken desires.

Sidebar: Gathering Data

Try the following techniques to get the goods on requirements.

• Interviews

• Facilitated requirements workshops

• Document analysis

• Surveys

• Customer site visits

• Business process analysis

• Work flow and task analysis

• List of external events and corresponding system responses

• Competitive product analysis

• Reverse-engineering of existing systems

• Retrospectives performed on previous projects

1 This paper was originally published in Software Development, July 2003. It is reprinted (with modifications) with permission from Software Development magazine.

Business Meeting Etiquette

As implementers, since we are continuously engaged in meetings of one sort or another, I think the following article by Donna Reynolds provides some good tips, which are common knowledge but needs to be imbibed as an habit, by practice.

Business meeting etiquette is basically good common sense, but one that takes a little practice. Certainly, we can all identify what not to do when planning and/or attending a meeting, but often what we really need is a set of guidelines as to how to do this successfully.

Attending a Meeting:

1. Be on time. Always arrive a few minutes before the meeting is set to begin. This indicates respect for the person planning the meeting and shows that you are organized.
2. Be prepared. Before the meeting, be sure to read any related material or review policies and procedures that will be addressed. You will be much better able to provide valuable input.
3. Bring a notebook and pen. Even if you don't take a single note, this will show that you are interested in the agenda and serious about your role at the meeting.
4. Participate. When the chairperson asks for feedback and you feel that you have something to contribute, be sure to do so. Ask questions as well.
5. Be polite and attentive. Never engage in cross-talk in a meeting and be courteous to the person who has the floor. Listen to what is being said and resist the urge to argue with anyone.
6. Conduct yourself professionally. Meetings are a great place to let people know that you are serious and have something to offer. Use this opportunity to demonstrate your knowledge and understanding.
7. Thank the chairperson. It's such a little thing, but thanking the person who organized the meeting is not only good etiquette, it is also a sign of respect.
   

Running a Meeting:

1. Plan ahead. If you are responsible for calling a meeting, plan ahead before sending out the meeting notification. Make sure that all interested parties are invited.
2. Set a clear agenda. In your meeting invitation, clearly state the agenda of the meeting. List the action items and request that attendees come prepared to address these issues. Attach related documentation for review and request input.
3. Set a time limit. In today's business environment, everyone is busy. By setting a clear time limit, you are showing that you respect your coworkers' need for time management as well as your own.
4. Dress professionally. You want to be taken seriously, and appearance is important. Even if it is "casual Friday," wear appropriate business apparel.
5. Encourage punctuality. Never be late to your own meeting! Set an example and plan to be in the room a few minutes before the start time.
6. Manage the meeting. Stick to the agenda and keep an eye on the time. Politely discourage cross-talk and make sure that every person has an opportunity to speak. Move the agenda along, but not so fast as to miss key points. If the meeting goes off-topic, remind the group of the agenda at hand and suggest that unrelated matters be addressed at another time.
7. Avoid engaging in petty bickering or arguments. Remain calm and diplomatic, no matter how heated the discussion may become.
8. Summarize. At the end of the meeting, sum up the action items and if necessary, request another meeting.
9. Follow-up. Once the meeting is over, follow up with all attendees. Send a list of action items, resolutions and issues that remain open. Thank people for taking the time to attend, and request feedback.

EFB - Before and After

Before Ramco EFB mplementation





















After Ramco EFB Implementation




















- Kuttan

Issues and Experiences with Short implementation projects

A short and sweet blog entry by Ashwin Pingali:

... We have been implementing all the Oracle 11i modules (Service, Financials, Projects, Manufacturing, Order Management and Purchasing) all in the span of 3 months. While we have been able to map all the business processes successfully and been able to demonstrate the end to end business process within Oracle, there have been some great learning experiences which can be of use in other short duration projects which have a large scope encompassing several modules.

Data conversion: While defining the data templates for the data that needed to be converted is one part of the exercise involving consultants, getting all the proper data from legacy systems, cleaning them up and formatting them to fit the template is quite a task. Technical personnel at the client's end who understand the data and the legacy systems and who are conversant with manipulating and extracting this data is extremely important to ensure that the time-lines can be met in these short duration projects. Dedicated personnel need to be assigned from the client's end for this task at least in major areas like: Item Master, Cross Referencing of items (when you have different product names all referencing the same inventory item), Templates and categories for the Item master, Sub-Inventories the accounts associated with each and the type of sub-inventories, Bills and routings for all make items, Price lists and modifiers, Warranty data (contracts), Install base items with existing and expired warranties, Customer Master, Vendor Master, Price Lists, and of course financial information. If Projects are being implemented then mapping the existing projects data into the data model within Oracle and transforming the data can be a cumbersome task, if the company has a large number of active projects.

User Acceptance: User acceptance and resistance can be an issue, but this is more prevalent when the customer is installing E-Business suite for the first time, or if users are being exposed to Oracle 11i for the first time as in the case of most CRM implementations where even though the client has been running Oracle 11i, the users in Service and Sales have not been exposed to the modules and thus are not aware of the navigation and do not understand the Oracle Lingo. For these users we need to conduct navigation training and expose them to the end to end process flows and transactions occurring in Oracle. Watching a screen capture video of the process flows can do the trick. Oracle SE comes with some key process flows but doesn't cover all of them. Creating these videos can be a good investment as this will help users gain a higher level of comfort with the application navigation and thus lower the resistance barriers to change.

Mapping the Business Processes to the features and functionality within Oracle: While this pretty early in the equation from a consultant's point of view, in this specific case it has posed lesser problems than the above issues. We have been able to achieve a great degree of success by adopting a series of CRP sessions with increasing complexity of scenarios structured around all the key business flows. As we had little customization in this particular exercise, complexity of scenarios revolved around more customer familiar data which brought up the first issue.

An interesting point though which most consultants may be familiar but nevertheless ignored CRP sessions conducted with actual data from client tend to be more effective and produce more enthusiasm among users than when we use seeded data or the VISION Demo database.

Software Change Impact Analysis Process

Source: http://expedoc.com/

This method is abbreviated to highlight steps applicable to software developers in general and may not be acceptable for projects developing safety-critical product. The method is based off my experiences with releases of avionics products that comply with Chapter 11 Oversight of Software Change Impact Analyses Used to Classify Software Changes as Major or Minor in the FAA Order 8110.49 Software Approval Guidelines.

The goals of a software change impact analysis (CIA) include:

1. To determine the scope of changes between baselines. The scope of a CIA is the list changes from one baseline to another. A change is a defect, an added feature or a removal of specifications, test procedures or code.

2. To optimize the reverification activities to ensure the changed product and documentation are sufficiently complete and correct. Sufficiently, in this case, means adaptable to the business and regulatory requirements for the product to:

- Do what it is specified to do,

- Be reliable,

- and/or be safe.

You may define flexibility into your reverification activity selection method such that very minor changes (e.g. spelling correction in a requirements document) to require only informal review and major changes (e.g. added feature) require layers and combinations of verification activities. Verification activities include various review, analysis and test methods.

Based on your company's needs, a CIA may be formal or informal. Informal analysis is analysis based only on expert judgment and experience. Formal analysis is based on expert judgment, experience and objective evidence.

A CIA may be performed when a problem report is added to your change tracking system or as a deliverable in the planning stages of a release cycle performed only on the problem reports within the scope of the release.

The following are considerations, as a system and/or for each change, to determine the scope of reverification activities:

(1) Traceability analysis identifies areas that could be affected by each software change. Changes include:

- After the root cause of each defect is identified, to determine the changes required to fix the code and impacted documentation (e.g. requirements, design, architecture, test cases and test procedures).

- When a new feature is added to an existing software baseline, to determine the scope of additions required to add the feature to the documentation and code.

- When specifications, test procedure and code are removed, to determine the scope of deletions required to remove the affected data from the documentation and code.

(2) Memory margin analysis

- If applicable, the memory allocation specifications are changed.

- For embedded systems, tracking peak memory usage during stress testing provides assurance that acceptable memory margins are maintained.

- When changes impact code that utilizes memory allocation or deallocation features, reverification activities may include using tools that check for memory leaks.

(3) Timing margin analysis

- If applicable, the timing specifications are changed.

- For embedded systems, tracking timing during stress testing provides assurance that acceptable timing margins are maintained.

(4) Data flow analysis

- If public or global constants or public or global variables are changed, identify the changes to data flow and coupling between components.

(5) Control flow analysis

- Identify when changes affect the control flow and coupling of components.

(6) Input/output analysis

- Identify when changes that adversely impacted the input and output (including bus loading, memory access, and hardware input and output device interfaces) specifications of the product.

(7) Development environment and process analyses

- Identify changes to the compiler options, versions, and optimizations.

- Identify changes to the linker, assembler, and loader instructions or options change;

- Identify changes to off the shelf software tools and libraries.

(8) Operational characteristics analysis

- Evaluate changes to shared aspects of the software architecture (such as changes to gains, filters, limits, data validation, interrupt and exception handling, and fault mitigation).

(9) Changes to Hardware

- Identify significant processor changes as this change typically result in major reverification.

(10) Partitioning analysis

- Identify changes that impact partitioning incorporated in the design.

(11) Document impact

- Additional features or changes to behaviors may require updates to user manuals or notes of the changes in release notes.

- Changes to the build process may result in changes to installation or manufacturing build procedures.

Based on the aspects of the changes noted above, the engineers can determine the reverification activities (Reviews, Analyses and Tests) needed ensure the target quality and reliability goals for the product are achieved.

Safety engineers can use this information to assess the impact of changes to the hazards analysis and/or system safety assessment.

Note: The added benefit of using this method is that when the contents of formal development documentation is kept current, the company’s intellectual property is protected.

FOUR COMMON ERP IMPLEMENTATION MISTAKES

FOUR COMMON

ERP IMPLEMENTATION MISTAKES

 

In the process of implementing an enterprise application suite like enterprise resources planning (ERP) or enterprise asset management (EAM), an almost infinite number of things can go wrong. A successful implementation depends not only on selection of the correct application, but on the quality of the communication between you and your application vendor or implementation consultants. Some of the more disastrous ERP implementations that you read about in the news – the ones that public companies blame for their poor financial performance, going well over budget and taking years to complete – might be blamed on the complexity of the product being implemented or perceived unresponsiveness of the implementation consultants. But the success of the implementation often depends on the customer organization and the project management ability of their implementation team. Those on the receiving end of an implementation are in a very challenging position because in many cases, none of the team members have been through an implementation before. Ostensibly, the team representing an application vendor or implementation consultant should be more experienced and professional, but miscues on their part are not unheard of either. In white papers, there is no shortage of advice about what best practices can lead to success. But equally important is a thorough understanding of what worst practices are to be avoided during an implementation. Problems during implementation are never deliberate. But in this white paper, we will review four practices that should be avoided unless one wants to go out of one's way to cause their implementation to tank.

 

Underestimate the strategic importance of the implementation process.

 

This is a very broad topic, but a failure to understand the various ways that an enterprise application implementation is strategically critical to your business can cause a number of problems. But perhaps the most common result of this cognitive failure is reflected in the type of people a company might assign to an implementation team and the problems that naturally ensue.

Some companies are understandably reticent to devote their most valuable human assets to a months-long implementation process and instead, assign more junior people to the team. This tends to create problems of vision as younger, less experienced employees of a company or those in staff-level positions tend to have an excellent grasp of their own jobs but a lack of understanding when it comes to the company's strategic goals or company operations as a whole. They may be more likely than their more experienced peers to be interested only in making their own job easier, perhaps at the expense of others in the organization, skewing project resources accordingly.

Another common error is to heavily load the team with C-level executives.

These senior players have an excellent grasp of where the company is today and where it needs to go tomorrow, so their buy-in is vital to the project. However, senior executives are often lacking when it comes to the specific processes and activities that are used within the company. A hands-off manager will be at a loss when it comes to discussing precisely how things are done within the company today and how, on a granular level, it is reasonable and desirable for business processes to be executed in the new software.

So who belongs on the implementation team? Choose middle managers who are

key users of the software and have extensive knowledge of both company strategy and detailed processes. They must be empowered to make decisions regarding the implementation, necessitating C-level buy-in and support, and will be responsible for determining how the application is used and dictating the business' process

flows for a long time.

 

Another way that a failure to appreciate the strategic importance of the implementation manifests itself is to assign what might be the right team but then give them no time to work on the implementation. Once the team is chosen, it is vital to make sure their regular jobs are backfilled so they have time to concentrate on the implementation. In too many circumstances, I have seen situations where someone is assigned to an implementation team and are told they still need to do their job and need to implement this ERP package on the side. That is not a viable situation as the implementation will be starved for resources. It will either grind to a halt or will be forced to move ahead with inadequate information, resulting in multiple problems at go-live.

 

Bite off more than you can chew.

 

There are two ways to try to do too much too fast with an ERP implementation.

One is to try to implement too much with regard to geography or sites all at

one time. Some ERP vendors and implementation providers advocate the "big bang," encouraging companies with multiple locations to take their entire organization live all at once. But often, that proves to be too much for an organization to handle.

 

In many cases, it is better to implement an enterprise application at one or two sites at a time. This allows a company and its implementation consultants to work kinks out of the business models and process flows that were decided upon by the implementation team.

Another way to bite off more than you can chew is to make too many dramatic changes in your organizational culture all in one felt swoop. When you buy packaged software, you are not only buying technology, but a way of doing business that can improve the efficiency of your organization. In many cases, elements of an application's functionality may represent business practices that you currently do not engage in, either because they have not been a part of your corporate culture or because they are not supported by your legacy system. Each of these process improvements and best practices are likely good opportunities to move your business forward, but trying to implement all of this functionality at the same time may prove to be too much for a business' management structure and employee base to absorb. Consider that Vitamin C is a very good thing, but trying to take too much of it at one time can upset your stomach!

In order to avoid disruption that can result from change that comes too quickly,

It often makes sense to take a more gradual approach. At the initial implementation, reach out to your functional leaders to see whether or not adding various elements of new functionality creates too great a burden. Sometimes better to go live with functionality you currently have in your legacy system, and then schedule add-ons when you are genuinely ready for them after an initial stabilization period.

 

Replicate your legacy system on new software

 

While trying to change too quickly is one way to hobble your enterprise application implementation process, trying to avoid change altogether can be just as damaging.

Some people just don't like change, and the idea of abandoning the way they have done things in the past upsets them. These people, if they are part of an implementation team, come into the project with their own paradigms and their own ideas of how things should work, which are often based on the old system.

Oftentimes, it does make sense to go live first on just enough functionality to replace the legacy system, but resistance to change of this nature can bring an implementation to a halt. A fervent desire to replicate an existing environment can be very granular, and team members may even have a specific idea of what screens they should see, what reports they should get and what buttons they click. People who are reticent to move away from their legacy system focus on the functions of the software rather than the business requirements behind those functions, and often request numerous modifications to the new environment, which cause cost to spiral without real business benefit.

It is important for an implementation consultant to understand the current processes and how the legacy system is being used. That is why a consultant will ask not only what processes are currently being followed, but what are the underlying reasons for each of these process. Sometimes, these questions are asked to make sure that each process is necessary, but this line of questioning can also determine the business need that process is fulfilling. An implementation consultant or applications vendor should understand that anything their customer does in their current process is likely done for a good reason, and it is their job to find what that reason is and then find the best way to satisfy that underlying need in the new software. Their goal should not be to replicate the way things are done in the legacy system. Indeed, most times, an implementation may bring a slightly different process flow, different screens and different reports. People assigned to a company's implementation team have to be able to think outside the box and realize that their business requirements are being met even if the screens and buttons are not exactly the same.

There is a relationship between the ability to successfully navigate this process and the degree to which the right people were assigned to be a part of the implementation team. It is crucial that the implementation team be able to look beyond the superficial elements of the legacy system, and see past the screens and reports to which they have become accustomed. They need to envision how the new application will be made to meet their underlying business requirements.

Implementation team members must be comfortable opting for a slightly different approach or a slightly different process in order to meet the strategic goals a new enterprise application is meant to achieve. In some cases, team members should even be empowered and unafraid to suggest organizational changes outside the application that will better accommodate a new process flow and make for a smoother implementation. Perhaps certain departments should be merged, or people who had worked on opposite sides of a building should be moved to better facilitate the new way things are to be done. With too great an attachment to the past, it is hard to realize a more productive and streamlined future!

 

Reinvent the wheel

 

A fourth and final way to kludge an enterprise applications implementation process is to reinvent the wheel by disregarding established implementation methods. Regardless of the implementation provider you choose or the enterprise software product you choose, your implementation team will come in with an implementation method, with specific steps to go through in order to ensure success.

This implementation method is proven, and has been developed over long experience at dozens, hundreds or even thousands of companies.

An implementation consultant or application vendor follows this method because it suits their approach and the software in question. While methods of different implementation providers may vary, a viable method will generally include four distinct steps:

 

Mapping: At this stage of the project, a consultant will identify the business processes you will implement and determine how, at a business process level, they will be handled by the software. IFS, for instances, uses its own IFS Business Modeler software for documentation of all process levels, automating the process of finding functional gaps and working them through to a solution.

 

Implementation/Definition: During the implementation/definition phase, the consultant and implementation team will take the process maps and work through the details. There might be several rounds of work routine documentation, modeling data migration to make sure processes are well-documented and they will work.

 

Testing: During the testing phase, the consultant and implementation team will tie all of the processes together and test them to make sure they will work. One way to do that is to run several days of the company's transactions through the system end-to-end in a controlled business simulation environment.

 

Rollout: After mapping, implementation/definition and testing are completed, it is time to roll the application out to users in the organization. This step involves training of the end users and ensuring that the IT infrastructure is in place to run the application prior to going live.

 

All of these steps are absolutely necessary. But sometimes, in a budget crunch or on a tight timeline, there is the temptation to cut out some testing or cut out some mapping. Even if you are not trying to reinvent the wheel in its entirety, it is not advisable to simply remove a few spokes to see how it holds up under load! Skimping on any of these steps comes with a degree of risk that needs to be recognized. Straying from the established implementation method creates the opportunity for things to go wrong at a critical time – during go-live week or after go-live as poor preparation comes home to roost. Typically, problems that result from diverging from proven methods cost more to fix than a more thorough and systematic implementation would have cost to begin with.

 

Jeff Kugler is a solutions consultant with the Milwaukee office of IFS North America.

Before entering the software industry, Kugler worked in manufacturing and operations. He has managed implementations both as a customer and as a consultant, and isactive in lean manufacturing advocacy both inside and outside of IFS. He holds aB.A. In computer science from Lakeland College, Sheboygan, Wis.

 

Sujitkumar Patil

--
Regards,

Sujitkumar Patil

ERP Implementation - Do's and Don'ts

- By Richard G. Ligus
The biggest single issue in ERP is the failure of a successful implementation. It is mind-boggling to continually encounter companies who make major ERP gaffes in this day and age, especially since most of the trials and tribulations of MRPII implementation were suffered and learned from in the early 1980's with alpha, beta and gamma releases.

So what constitutes failure? Several thing come to mind: (1) Not making the promised return on investment,(2) Inordinately extending the implementation schedule and start-up date,(3) Running over budget by unconscionable variances,(4) Grinding the organization to a crawl pace, or the severest of all consequences,(5) Stopping production and/or not delivering orders to your customers.

Industry statistics show that >60% of ERP implementation starts historically fail. Does this mean that you are doomed from the start? Of course not, if you learn from the mistakes of others. So the pertinent question is what are the main causes of ERP failure and what can be done to prevent this from happening to you?

The 12 Cardinal Sins of ERP Implementation
There are twelve major reasons for why companies get bogged down or fail in implementing ERP.
(1) Lack of Top Management Commitment The propensity of top management to delegate the oversight of an ERP implementation to lower management levels often results in (1) being "out of touch" with critical events, or (2) the lack of understanding of the size, scope, and technical aspects of the project, and subsequently, the lack of proper commitment of time and resources required for a successful implementation. The result is a failure waiting to happen.
(2) Inadequate Requirements Definition Surveys have shown that inadequate definition of functional requirements accounts for nearly 60% of ERP implementation failures. This is simply a matter of not comprehensively and systematically developing a quality set of functional requirements definitions. This leads to the second greatest cause of ERP implementation failures: poor package selection.
(3) Poor ERP Package Selection Poor package selection occurs when a company has inadequately developed functional requirements definitions. It also occurs when staff members assigned to ERP projects do not take the time to run the screens of the new system, as they would during their daily work tasks, to find out if the software package features are adequate for their needs.
Another reason we have found is executives, familiar with an ERP system from a last job they held, implement the same system in their new company without defining functional requirements. We have also encountered companies who made major gaffes by selecting a package at the top levels of a company without intimately knowing its characteristics. What often results from this is the ERP package doesn't fit the organizational needs, or that the package selected takes longer to process daily work tasks.
We have also seen executives select a distribution package for a manufacturing environment, or a manufacturing package for a distribution environment, for obscure reason, such as liking one salesman over another.
(4) Inadequate Resources The third greatest reason for ERP implementation failures is inadequate resources. Many companies will attempt to "save dollars" by doing everything on an overtime basis, whether or not there are adequate skills within the company, extending individual work loads to 150%. This approach can be a "kiss of death" for the program. Time and time again we run across this mistake in ERP implementations. The financial and emotional drain of what seems sometimes to be perpetual extensions, reschedules and delays of implementations takes its toll. People burn out after having put in extensive hours over a long period of time.
(5) Resistance to Change/Lack of Buy-in The lack of a change management approach as part of the program can prevent a program from succeeding. Resistance to change is quite often caused by (1) A failure to build a case for change, (2) Lack of involvement by those responsible for working with changed processes (3) Inadequate communication (4) Lack of visible top management support and commitment, and (5) Arrogance. A lack of buy-in often results from not getting end-users involved in the project from the very start, thereby negating their authorship and ownership of the new system and processes.
(6) Miscalculation of Time and Effort Another cause of ERP implementation failure is the miscalculation of effort and time it will take to accomplish the project. Companies who treat an ERP selection, evaluation and implementation comparable to buying a washing machine are doomed to failure.
(7) Misfit of Application Software with Business Processes One of the main causes of ERP implementation failure is the misfit of application software with the company business processes. This failure -- to examine underlying business process flaws, and integrate the applications with the business processes, causes loss of productivity and time, and ultimate benefits.
(8) Unrealistic Expectation of Benefits and ROI Another significant cause for ERP implementation failure is the unrealistic expectation of benefits and return on investment. Software providers are notorious for overstating the benefits in terms of ROI, when the total costs of the project have been understated. Often left out of the total costs are costs of planning, consulting fees, training, testing, data conversions, documentation, replacement staffing, and the learning curve performance drop. When this happens, a company doesn't stand a chance of achieving the ROI it anticipated.
(9) Inadequate Training and Education Another of the biggest causes of ERP implementation failure is inadequate education and training, which are almost always underestimated. ERP-related training is crucial as most employees must learn new software interfaces and business processes which affect the operation of the entire enterprise. The corporate culture is impacted by changes in the company’s business processes, and shortchanging this part of the ERP implementation leads to much pain and suffering downstream.
(10) Poor Project Design and Management A major mistake is to short-cut critical events in the project plan, such as time for documentation, redefining and integrating processes, or testing before going live. Another common mistake is made when a company leaves out the self-examination of business processes and uses ERP to cover-up weaknesses. It is easier to buy software than to perform the more difficult task of identifying weaknesses and opportunities for improvement.
(11) Poor Communications One of the causes of ERP implementation failure is poor project communications, beginning with a failure to announce the reason for the up and coming effort, and continuing to advise the organization of the progress and importance of the ERP implementation to the company. Poor communications prevent different parts of the organization from assessing how they will be impacted by changes in processes, policies, and procedures. Communications are a vital part of managing change in a corporate environment.
(12) Ill-advised Cost Cutting Another of the key causes of ERP implementation failure is ill-advised cost cutting. In an effort to avoid temporary conversion costs, some companies take a very risky route and go live at multi-plant sites simultaneously, subjecting all plants or some plants to a total shutdown should there be a false start-up. This is suicidal. Others attempt to unrealistically compress the schedule in order to save on expenses, only to eventually overrun both schedule and budget. We feel that ROI should take a "back seat" when upgrading an important part of a company's infrastructure: the information system. Instead the implementation should be treated as an upgrade necessary to maintain or gain a strategic and competitive advantage.

Pragmatic Applications
The first corollary of ERP or information systems implementation is: Information systems are part of a company infrastructure, and therefore are strategic to the company's survival and success. If a company does not consider IS as one of its critical success factors, chances are, the competition does.
The second corollary of ERP or information systems implementation is: ERP and information systems are there to support business functions and increase productivity, not the reverse. The driver for an ERP implementation should be to increase a company's competitiveness, not the adoption of a new religion that bends or distorts how a company conducts its business.
The third corollary of ERP or information systems implementation is: Learn from the successes and failures of others and don't attempt to reinvent the wheel of ERP implementation practice. There are time-proven approaches that can enhance the success of the ERP implementation. Here are a few:

High Employee Involvement
Get as many employees to participate heavily as practicable in accomplishing the functional requirements definition. The workers know their work and what they need to compress time. If they do not, use an outsider who does. Use a knowledgeable team to review and select packages. Get as many employees as practicable involved in the implementation phase. This will foster ownership and buy-in.
A Comprehensive and Systematic Approach
Use a comprehensive and systematic master plan that addresses all parts of an ERP systems implementation: development of IT strategy, requirements definition, review/selection of software, hardware, communications, unit testing, systems testing, conversion, resources, education/training, resistance to change, etc.
Adequate Resources
Provide adequate technical and administrative resources to allow employees breathing room. Perform cost/benefit analyses so that you know how much the entire implementation is going to cost and identify the results that will be achieved.
Extensive Education & Training at all Levels
Provide adequate training for most employees, including upper and middle management.

CIOs' Focus

As companies gird their loins in the face of rough economic times, CIOs are shifting their priorities toward broader business issues; at least that is what a recent CIO Insight Survey would indicate.
Here the CIOs surveyed ranked their 2008 top 10 priorities:
Deliver Better Customer Service (35%)
Improve Business Processes (35%)
Contributing to the Creation of New Business Strategy (31%)
Cutting Costs (29%)
Coming up with New and Innovative Products (21%)
Generating more Business from New or Existing Customers (20%)
Improving Worker Productivity (20%)
Ensuring Business Continuity (19%)
Complying with Regulatory Compliance (18%)
Competitive Differentiation via IT (16%)
These priorities are conspicuously absent of more traditional technology-focused items like Virtualization, SOA, CRM, ERP, Outsourcing, etc. Hopefully this shows a shift in the mindset of CIOs as seeing technologies not as a priority but as a means to achieving priorities; if so, then this is good.
Source: Gantthead

User value creation through smart interface

Ramco aviation software – IBM Filenet interface

Filenet, a company now owned and assimilated by IBM, developed software to help enterprises manage their content and business processes. The FileNet P8 platform, their flagship system, is a framework for developing custom enterprise systems, offering much functionality out of the box and capable of being customized to manage a specific business process. Filenet has a unique solution for managing scanned images of printed documents. To know more about Filenet read http://en.wikipedia.org/wiki/FileNet

By way of a smart interface to filent document management system, we have offered a unique solution to one of our customers for processing paper forms and documents involved in transactions. Screen shot below indicates how images of paper invoices (sent by suppliers) are indexed, stored and verifiable on-line from our invoice processing transaction. Besides filenet enables an invoice processing user to add remarks, highlight texts and other limited editing works on the document image!

End user values:

Time savings – A repair order approver can scan through the various proposals, design diagram etc on-line, instead of waiting for the deck of documents before approval

Job simplification - Invoice matching person need not scan through hundreds of invoices before clarifying a query from a supplier. It’s available on-line, and even enters some remarks, if required and save the document.

Becomes a hero – Purchase executive answer a supplier query on an invoice filed months ago, in few seconds and goes home on time to watch his favorite show!

-Kuttan

How to Build Trust for Better Business-Requirements Gathering

- Elizabeth Larson, PMP, and Richard Larson, PMP, Computerworld

One of the most difficult phases in project management is gathering business requirements from stakeholders. Requirements are often vague because it is difficult for customers to articulate their needs before they see the end product. When business customers and the project team have a relationship built on trust, they can work together more quickly to produce a product of value to the organization. But how do you go about building trust?
Before the formal requirements-gathering process begins, it is important to discuss the business context of the project with the sponsor. Requirements need to be gathered and managed in relation to the organization's overall vision and strategic direction. They must link to business goals and objectives. When requirements lack this linkage, which we call upwards traceability, there is a high likelihood that customers will request features and functions that not only are out of scope, but also promote their own agendas.
In addition to meeting business objectives, requirements should also solve business problems. One of the most common complaints from business analysts and project managers who gather requirements is that their customers bring them solutions and neglect the underlying problem. Often, the result is a solution that goes unused. Here are some questions to ask to uncover this business problem:
What is the business pain?
What is currently limiting you?
How do you describe your need or problem?
How did you first realize status quo wasn't good enough?
What opportunity arose?
What are you trying to solve?
Initial meetings with the sponsor to discuss the business and project vision, as well as the business problems, can be a helpful way to establish rapport and begin to build trust. Focusing on the business need and vision demonstrates business acumen, which in turn builds respect and leads to trust.

Techniques for Building Trust

There are a variety of techniques that are typically used in requirements elicitation. One of the most common is the facilitated session, in which a facilitator enables key stakeholders to articulate their requirements in a formal meeting. This approach has many advantages, including using the synergy of the group to build relationships and trust. Another common technique is the one-on-one interview. This technique is a way for business analysts and project managers to meet individually with stakeholders. Through these individual meetings, trust can be built in several ways:

Assess commitment
Some stakeholders don't like to make decisions or agree to decisions in meetings. One-on-one meetings provide a safer venue to discuss real needs behind the stated -- and unstated -- needs.

Address individual concerns
Some people are more inclined to reveal their true concerns about the project and the other project stakeholders in one-on-one interviews, rather than in large groups. When elicitation is limited to facilitated sessions, these concerns go largely unaddressed.

Address negative behavior
Sometimes stakeholders either dominate meetings or demonstrate various types of behavior that negatively impact the group. By meeting individually, analysts and project managers can focus on the behavior and, together with the individual, determine ways to reduce its impact.

Recognize individual achievement
There are individuals who aren't comfortable with public recognition. With these stakeholders, individual accomplishments are better recognized in private. Each of these individual meetings is a chance to establish rapport and ultimately build relationships and trust.

Barriers to Elicitation

Distance of stakeholders
Ideally, all key stakeholders should be based on the same floor or in the same building. The farther the business experts and sponsors are physically removed from the analyst and project manager, the more difficult requirements elicitation becomes. Teleconferencing, videoconferencing and Net meetings are often used for elicitation, but each presents significant challenges that make the process cumbersome.

Inadequate time to determine requirements
It takes time for business experts to determine their requirements and, specifically, the details of those requirements. By analogy, homeowners can discuss certain aspects of the house they want to build, but rarely can they articulate all their detailed requirements at the first meeting with the architect and builder. This is true for all business requirements, regardless of the project size. Complexities arise when different stakeholders have different requirements that must be reconciled and finalized.

Project misalignment with corporate objectives and goals
When this happens, executive support and stakeholder availability tend to evaporate. Arriving at meetings late, attending them irregularly, coming unprepared and not answering voice mails and e-mails are all symptoms.

Lack of understanding of the political landscape
Analysts and project managers who begin projects without having a clear picture of the political landscape will struggle, and the project is likely to take longer than expected.

Distrust
The most common reason for stakeholder caution and concern is distrust, caused by one or more of the following:
Fear that the end product, such as a new system, will dramatically change or eliminate their jobs.
Fear that the end product will impede or slow their workflow in the name of trying to improve it.
Fear that familiar software (such as the existing system or Excel spreadsheets) will be replaced by something incomplete, inaccurate or difficult to learn.
Without an established relationship and trust, it will be very difficult for analysts and project managers to elicit the necessary requirements.

Building Trust

Trust usually takes time to develop. Our trust of those involved in our projects may be based on past experience, personal filters, culture (organizational, geographical and otherwise) and a wide variety of factors that can influence our judgment. Analysts and project managers don't always have time to let relationships develop, so here are some things that can be done to build trust quickly:

Discuss the project objectives openly
If reducing head count is a business objective and the project in question may contribute to meeting that objective, the project manager or analyst needs to communicate the possibility to the stakeholders if asked. Trust will not be built by avoiding the conversation or asking the stakeholders to discuss it with their bosses. Such a conversation can lead to one about the advantages to the employees of actively participating to help the organization meet its goals.

Communicate bad news
If the project is behind schedule, needs more resources or is suffering from a lack of stakeholder participation, it is important for project managers and analysts to address these issues with the sponsor and other appropriate team members.

Encourage laughter
There is a strong relationship between laughter and trust. Having fun in meetings and laughing appropriately (not hurtfully) even under pressure builds a sense of team solidarity and a desire to work together toward the intended project outcome.

Define clear roles and responsibilities
When not defined, not only do tasks overlap, but they more commonly fall through the cracks, which invariably leads to finger-pointing, blame and lowered morale. Clear definition helps prevent territorial squabbling and decreases the chance of misunderstandings and subsequent project delays.

Maintaining Trust Over Time
Once trust is established, it can lead the team members through project difficulties. However, once broken, it cannot easily be regained. Some common trust breakers include the following:

Disclosing confidential information
While it's important to encourage open communication, confidential information can't be disclosed. It is acceptable to tell the inquirer that the information is confidential. It is also acceptable to set up initial communication guidelines.

Creating a competitive environment
Competition by its very nature produces winners and losers. While some stakeholders can be positively charged by competition, others may view competition with resentment and even anger, leading to a weaker relationship.

Communicating within a hierarchy
When we keep the entire team informed, we reduce the likelihood of gossip, speculation and low morale.

Micromanaging
Hovering over subordinates can give the impression that the manager doesn't trust them, and they in turn will develop a mistrust of the micromanager.

Failure to make decisions
Being indecisive can be destructive for a team looking for leadership. Being decisive doesn't mean making all the decisions or being authoritarian. It does mean taking appropriate action to resolve real issues, remove project barriers and move the project forward.

Elicitation = Relationship Building

Requirements elicitation requires building relationships and trust among the project stakeholders. When trust is absent, the requirements elicitation process will take longer, be incomplete and will generally become an unpleasant experience for all concerned. Although building relationships takes time and effort, it can actually shorten project time and result in improved project performance.

Elizabeth Larson, PMP, and Richard Larson, PMP, are principals of Watermark Learning, a Minneapolis-based project management and business requirements analysis training company.