Coping with Scope: Eight Real-World Strategies

Good set of lessons in this article by Michael Wood, which appeared in gantthead:

If history has taught us anything it is this: “No matter how well a business application project’s scope is defined, it changes time after time.” Managing the scope of a project is always plagued with some form of scope creep. Scope creep has been the bane of project managers since project management began. The scope of project is somewhat fluid in nature and tends to morph as the project progresses. Like hurricanes, the path followed can only be projected within a certain margin of error. However, hurricane path forecasting utilizes different models, each based on a series of uncontrollable factors that can and do change over the course of its life. The closer the hurricane is to landfall, the more accurate the projections.

Unfortunately, most scope-management frameworks are designed around the definition of a finite scope based on limited knowledge and advocating tight controls to manage change. Scope changes can be driven by many factors, including new ideas, regulatory change, change of needs, poor understanding of requirements, heuristic discoveries, financial circumstances, changes in leadership and more. In addition, in the absence of an agreed-upon objective and quantitative methods assessing the impact that scope changes will have on the success of the project, emotions and politics will most likely rule the day.

The challenge is how to weave change and scope recalibration rules into the fabric of the project that proactively allows for resources, budgets and delivery times to change without attracting management’s ire. Here are eight strategies you might find useful in meeting the scope management challenge:

1. Use a Discovery Phase to establish a stable scope

One of the quickest ways to improve your ability to develop an accurate and creep resistant scope is to conduct a “scope discovery phase” out of which a detailed understanding of deliverables will be developed. Typically, these phases are like mini design phases with requirements traceability from objectives through workflows to applications, programs and data structures. The result is a very detailed list of deliverables making it easier to spot any additions to the mix. In addition, since the deliverables can be classified as to their complexity and type, it is possible to use standard estimating metrics to compute the effort needed for completion. Finally, understanding the business processes, applications, programs and data structures in play allows you to identify the talent and resources needed to support the effort. Discovery Phases typically take from one to three months to complete and consistently yield scopes that are 95 percent accurate (and that ain’t bad!).

2. Develop formula- and event-driven models for establishing budget needs, resource requirements and delivery dates

Imagine a project scope that was virtual in that it was constantly recalibrated based on predefined criteria and events. Only the most uninformed and naïve believe that the factors that influence a project remain static over the life of that project. Every experienced project manager knows that the scope set at the beginning of a project in terms of budget and deliverables is at best an educated “best guess” at the time and is going to change; thus the reason for “change orders”.

A mature management will want to approach projects in a way that the remaining time to complete and monies that need to be spent reflect the most accurate appraisal of reality that can be had. However, in most cases management wants to cast early estimates in concrete and threaten grave punishment to the project manager should they miss budgetary and delivery date targets. This in turn often incents those leading the project to lie about progress, representing to management that the project—amazingly--is as complete as the monies that have been spent. The old adage that “project progress can be declared on track right up to the remaining 10 percent of the effort” has roots in this contradiction--and management’s stupidity in such matters.

A more mature and sane approach to managing projects is to recognize from the beginning that events can occur that would substantially impact the project’s budget and delivery date. Based on this analysis a set of planned recalibrations can be forecast along with the trigger points that would indicate a change in scope was needed. Being proactive in this regard is the key to being intelligent about true scope management.

3. Drive scope changes based on delivery date impact

Truth be known, when push comes to shove, delivering a project on time is more important than delivering it on budget about 99 percent of the time. This is because any project that sports an attractive ROI is worth having sooner than later. In addition, most mission-critical projects have a window of opportunity that, once closed, might not reappear for some time. Using a Delivery Date-driven approach to scope management provides a great yardstick for evaluating whether a change in scope is worth the acceleration of delay of the project’s due date.

Under this method, the cost of the change would be equal to the actual cost to perform the work plus/minus the loss/gain in return. This pendulum swings both ways as sometimes the elimination of a deliverable can shave precious time off the delivery date. For example, assume a set of deliverables (not functionally critical of course) were estimated to cost about $75,000 and take two months to deliver. If the original project budget were $5 million and the estimated return was 20 percent, then the monthly value of the return would be over $80,000 a month. Therefore, to add this change to the project would have a cost of $235,000 (75k + (80k X 2), while deleting these deliverables would have a equivalent savings. This approach can be very sobering to management and keep things very honest and above board.

4. Build recalibration point into the project plan based on changes to external factors and knowledge gains

For over 12 years, I have been building recalibration points into project workplans. These points often coincide with milestones or phase breaks and by design are planned opportunities to revisit the scope of the project and its value to the organization. Not once has management seen this as an issue--it has embraced the forward-thinking it represents, providing them options at critical junctures during the project. Each recalibration point consists of a set of tasks that include validating the delivery time, resources requirements, opportunities for acceleration, assessment of new risks, market conditions, external events and of course a recasting of the budget. Once completed, a “go forward” recommendation is submitted to management and--if approved--the project continues.

These short sanity checks only take a few hours to perform because they are planned, and most of the work completed before the date due. There are times that without the use of this strategy, projects that ended up being successful might have crashed and burned in failure.

5. Drive budgets and delivery dates using more granular deliverable definitions

In September of 2007, gantthead published my article entitled “Identifying Requirements from BPI Documentation”, where I presented a method for extrapolating very granular requirements from high-level BPI documentation. By granular I am referring to every explicit and implicit input, process and output that is needed to support the improvement opportunities indentified in a BPI initiative. This same approach works outside the BPI environment and is based on a set of rules that can be applied to any set of processes and data structures. I encourage you to read this article--the approach has been well-tested and goes hand-in-hand with the discovery strategy previously presented.

6. Add a new deliverable assessment/acceptance process to the project governance framework

Nothing vets a proposed change to a project’s scope than a pre-defined process for assessing and evaluating the change requests. As stated in the beginning of the article, people are going to change their minds about what they need and want—it’s just part of human nature. To suppress this process is to invite people to buy out of the project and become points of continued angst and risk. Every week, change requests should be consolidated and an associated impact analysis performed. Then, as part of the normal project portfolio status meetings the requests should be scored and ranked based on the assessment criteria (i.e. value to project, impact on delivery date, cost, resource availability, trade-offs, etc.). The project plan is updated (budgets, timetables, etc.) for changes that are approved. In this way, the change process is orderly and manageable and--voila!--scope creep a thing of the past.

7. Allow for a deliverables trade-off process

Sometimes, requested increases to the scope to a project can be accompanied with offsetting scope reductions. This is often the case when budget is rigid and, in essence, the organization wants as much as it can get for a finite investment. Under this strategy, people requesting new deliverables must also be willing to trade-out other deliverables. Just like in the above strategies, this is best accomplished using a predefined set of evaluation criteria so the value of the trade-offs can be quantified, reducing the emotional side of the equation in the decision process as much as possible.

Once again, the project plans are recalibrated to reflect the changes approved and things continue on, business as usual.

8. Create a “time boxes” releases strategy

“Time boxing” is a well-accepted method for chunking deliverables into a series of smaller groups that can be delivered quickly. Not all projects lend themselves to time boxing, but many do. The most difficult part of this strategy is to get people to accept a partial set of deliverables. Often, those using business applications are fearful that they will only get one chance to get what they want and thus pile on the requirements until the project is so big and costly they end up with nothing at all. This of course reinforces their fear, and thus a cycle of self-fulfilling prophecies occurs.

The interesting dynamic is that once time-boxed projects are successful, the user population usually insists on this approach on all future projects. This presents an excellent opportunity to implement a formal release strategy that offers upgrades to the application base on a quarterly or semi-annual basis. Once in place, maintenance costs are typically reduced as a much more prudent approach to change is management is employed. Under the release strategy approach, requests for application improvements are accumulated and mapped into the existing application base.

Similar requests can thus be combined to take advantage of any economies of scale that might exist. This reduces the overall cost and labor that would otherwise be experienced. The improvement requests are then parsed into a series of logical releases based on what can be accomplished in three- to six-month segments. Few IT organizations ever really get this level of order and stability to their project environment when it comes to the care and feeding of the installed application base. Of course, this approach does not lend itself to new application deployments like an ERP, CRM or data warehouse project.

Summing it up

Armed with eight real-world strategies, you are ready to tackle and master the process of project scope management. Scope creep should be a thing of the past and, if successful, you should expect your PM prowess to be that of legend. Good luck!

Product Manager’s key to success

I just happened to see this quote from Bill Cosby.

“I don’t know the key to success, but the key to failure is trying to please everybody”

How appropriate for product managers?

All product managers should have this quote stuck next to their desks so that it is in your face as a reminder. We cannot build a product that is good for everyone - pick the target buyer (who will buy) and then execute like hell. Use the target buyer to handle all the “what if we do this …” or “what if the user wants to do this …” ideas people throw at you.

- Gopal Shenoy

Project Management - Art as well as Science

Follow the link below for a paper by John Gunson and Jean-Paul de Blasis on evolution of Project Management from early 1990s to date (what follows is the introduction piece from the paper):

http://hec.info.unige.ch/recherches_publications/cahiers/2003/2003.02.pdf

At the beginning of the 1990s ERP Implementation Projects followed a classic approach to Project Management. Once Top Management had decided on the ERP solution to be implemented, usually with an Editor such as SAP (the leader), ORACLE Applications, J D EDWARDS, PEOPLESOFT or BAAN, then a Project Manager was designated. Often this was the I.T. Manager who needed to assume the Project Manager role as well.

Helped by the Editor, the Project Manager itemized in detail the tasks to be carried out, attached resources to these tasks and fit the time-scales and budget as per Top Management guidelines/directives. Tools were available to help this process - for example Microsoft Project. This allowed the preparation of a Gantt Chart, and use of Critical Path and techniques to monitor Project progress.

As the decade progressed there was a natural evolution. The tools became more sophisticated allowing for what if scenarios, and Project slippage could be automatically evaluated if a task or set of tasks took longer. There was a tendency for Editors to set up strategic partners: Integrators, who worked with their customers to achieve implementation.

But the approach remained scientific, and a drawback was that slippage (delays, costs, deliverables) tended to be identified but after the fact. Actually ERPs proved more difficult to implement than anticipated with escalating delays and cost overruns. The Project Manager was looking in the rearview mirror and constantly correcting. What was needed was a proactive approach which allowed the Project Manager to anticipate problems and if possible avoid them or at least plan for them and have contingencies.

At the same time that the classic Project Management approach was being seen as incomplete, experience was showing another interesting characteristic: that the failure factors difficult to correct were often human related rather than technical.

In other words, it was not simply a matter of ticking off tasks done. There were ‘feelings’ involved which could lead to latent or evident resistance to change.

From the literature: Ann Miller says in an article with the organizational change theme ‘Some plan and lead change, others manage it, still others accommodate change, and many simply try to cope with it” (MILLER, 2001).

In an article also on the theme of organizational change, Pettigrew, Woodman and Cameron throw down the gauntlet for future research by suggesting that Management scholars are curiously incurious about why and how certain organizations consistently outperform their competitors. They note also that the link between change capacity and action to organizational performance is not clearly sought in empirical studies. (PETTIGREW, WOODMAN, CAMERON, 2001)

Read more by clicking the above link!

Training Effectiveness...

Here is a link to a very insightful article (if you can patiently click through the pages) titled, POST-IMPLEMENTATION USABILITY OF ERP TRAINING MANUALS: THE USER'S PERSPECTIVE by Scott, Judy E:

http://www.allbusiness.com/management/912850-1.html

HEADNOTE
Training users is critical to the success of ERP implementations. An important aspect of training is documentation in the form of training manuals. However, the effectiveness of the training manuals will depend on their perceived usability. In this study, data on users' perceptions of ERP training manuals, more than two years post-implementation, are analyzed for usability dimensions of task support, learnability, navigation, and presentation.

PROBLEMATIC ERP IMPLEMENTATIONS are often associated with inadequate user training (Brown and Vessey, 2003; Roberts et al., 2003; Scott and Vessey, 2002). In a recent study of 30 manufacturing firms, user training was their top ERP problem (Duplaga and Astani, 2003). Training is consistently an under-budgeted item and is often the first item cut in the budget (Slater, 1998), despite Gartner's finding that each hour of effective training is worth five hours to the organization because well-trained users (1) reach the required skill level in less than a quarter of the time, (2) require less assistance from peers and help desks, and (3) spend less time correcting errors (Aldrich, 2000). Organizations spend as much as 50 percent (Davenport 2000) to as little as 5 percent of their ERP project budget on training (Wheatley 2000). Gartner research asserts that companies allocating less than 13 percent of project costs to training are three times more likely to have their ERP projects fall short of business and project goals compared with companies that spend 17 percent or more on training (Aldrich, 2000; Burleson, 2001)...

Two Great Wastes and Underutilizaton of Human Potential

We can get some good insights into Communication and its impact on our potential, from the following piece and attached paper, by Hal Macomber and Gregory Howell:

Two Great Wastes™:

Not Listening

Not Speaking

We need a story that is embraced and retold that champions the success of teams who operate in a setting of respect and dignity speaking freely while engaging in deep listening.

Not listening has been cited as the source of the tragedies of the NASA Mars Climatic Orbiter and the Columbia shuttle. Not listening results in resignation and resentment as people attempt to change a situation only to find no appreciation.

Not speaking deprives others of wisdom, perspective, and insight. Not speaking is culturally reinforced at young ages. We learn that speaking up can lead to punishment. We stifle ourselves out of fear.

Both not speaking and not listening become habits in our life and in organizations. That is the good news. The habit can be changed. The initiative for change can come from anyone taking an act of leadership.

Greg and I claim listening is the master skill of the leader. A corollary to that skill is creating the circumstances for others to speak. The only thing keeping us from bringing forth that leadership is the current story about the exercise of power and control on projects and in organizations. We must change our story of how we are most effective. We need a story that is embraced and retold that champions the success of teams who operate in a setting of respect and dignity speaking freely while engaging in deep listening. Let's battle the Two Great Wastes...

Here is the link to their paper:

http://www.iglc2004.dk/_root/media/13105_079-howell-macomber-final.pdf

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.