INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

Where Does Agile Fit in SAP Projects?

November 12th, 2012 by
Agile on SAP projects

Agile SAP Success

After offering insight based on my personal experiences around “Agile Project Methods for SAP ERP Projects?” I thought it would be helpful to highlight a couple of areas where Agile does work.

  • Design sessions
  • Development efforts (i.e. coding)
  • Data conversions

Once you begin to move very far beyond these areas you quickly encounter dependent work streams that need much more coordination.  Those additional dependencies make it difficult to apply Agile methods.

While Agile tends to emphasize the 1 week to 1 month “sprint,” I would define a “sprint” in more of a completed requirements and planning package rather than a pure time-box approach.

 

Applying Agile Methods to ABAP Software Development and SAP Data Conversions

Development (ABAP, Java, or other coding)

Since Agile methods have been used for some time with small, discrete components of software development I won’t spend a lot of time there.  On a typical SAP project you will end up with a functional spec which defines the program requirements and a technical spec which informs the development details.  Even though the more typical “Agile Manifesto” method would not require the documentation it is well-placed on an SAP project.  In fact, it is foolish not to have it for long term support and maintenance. 

Development can work well for the Agile stages of build / prototype, demonstrate, gather feedback, adjust, and repeat.  The key here is to limit the number of these “Agile” cycles to no more than 3 for software development.  By 3 cycles I mean 3 completed cycles too.  This is not a demonstration with feedback that is only partially built.  If the feedback cycle is not completely implemented then it is not a complete cycle.  Even though Agile would consider these “sprints,” I would consider them a FAILED sprint if the requirements of the current plan, or the subsequent plans, are not fully realized in the prototype or demonstration.

SAP Data Conversions using Agile Sprints

With data conversions I suggest at least 3 complete cycles or “sprints” (not including a minimum of 1 mock go-live conversion, probably 2 or more if you can). 

  1. Build the initial conversion program to all of the requirements (again, partial requirements do not count as a full cycle).
  2. Pilot a test conversion with all data, no matter how much fails, and capture all necessary changes.  This will include data dependencies and sequencing.  At this point you will be lucky to achieve a 70% success rate when considering all of the data dependencies.  This step is not about getting things perfect but about identifying data and programming issues to resolve.
  3. Implement all SAP data conversion changes the conversion pilot exposes, script every conversion step and rough timings, and aim for a successful test target of at least 90%.
  4. Make additional changes and attempt to follow the scripted conversion, making adjustments to the conversion script where necessary, and achieve a goal of at least 98% conversion completeness and accuracy.

Once you achieve this level of conversion consistency it is ready for a mock-conversion.  These Agile “sprints,” or as they are starting to call them now “Scrum-ban” (as a spinoff of Kanban) will help to ensure a successful data conversion.

Agile Design

Agile processes or sprints, are effective for design sessions.  Done correctly, this allows a customer to be exposed to the system earlier, provide better insights and results, and generally improve overall solution fit.  

One of the major differences with Agile Design vs. the traditional SAP Blueprint is the timeline.  An Agile Design approach requires more time because there is an element of system setup and solution discovery.  In the traditional Blueprint approach, everything is done on paper and many details are often missed.

When you combine an Agile Design approach with Lean principles, you can see overall project benefits in quality, cost, and overall solution stability at go live.  What this means is that during the design you are actually doing small “sprint” type activities to build out key areas of the solution.  Design sessions become playback and adjustment.  One key consideration with this approach is that you will not have 100% of the integration areas, or solution areas completely set up and defined.  This is important to understand.  If a customer expects to see perfection during Agile Design then a more structured waterfall approach, with a formal paper Blueprint would be required before any system solution activities are performed.

Conclusion on Agile in SAP or other ERP Projects

Even with newly packaged Scrum, Agile, or other methods, on an SAP project there are so many moving parts and work streams to coordinate that there is no substitute for a good waterfall project approach.  Using “Agile-like” methods for the ABAP development or data conversions is not a substitute for good project management either.  Done properly this approach can work well as long as it is carefully managed along with the rest of the work streams.

The Agile approach that works for an SAP deployment is one with a mix of both Agile for discrete task areas combined with a waterfall overlay.




Popular Searches:


  • erp prototype
  • what is erp prototype
  • what is prototype for erp

Related Posts:

ERP Project Plan: Getting Real (Part 2)

April 16th, 2010 by

SAP Project DimensionsThirteen Dimensions of Project Scope

In many cases the ERP project plan is not worth the paper on which it is printed. Worse yet, many project managers shoot themselves in the foot by prematurely committing to a project schedule and budget that sets unrealistic management expectations. The problem is once cast, expectations will not go away and only come back to haunt you later.  Could this be one reason why many ERP projects “fail”?

Even when the schedule and budget are “formally” published, inadequate definition of project scope (and boundaries) is a major reason the plans are invalid and quickly tossed out the window. In other words, we need a project scope, schedule and budget that closes expectation gaps. A project plan people can believe and use to actually manage the project. What a crazy idea!

Project scope not only drives baseline project schedule and budget; but it also sets user expectations regarding what they will get (and not get) within the software functionality. When users are later told something is out-of-scope they really need, the project is in for many unhappy users or scope creep that results in surprise cost and schedule overruns. Take your pick.

Finally, a good scope document represents a major tool for the project manager to control the project. Like a referee in a football game the project manager needs the ability to throw the yellow flag. However, it is always best when all parties involved understand the rules of the game before the ball is put into play.

Purpose of this Project Scope Article

The purpose of this article is not to imply good or bad scoping decisions. The goal is to assist the practitioner in understanding the key elements of scope, potential implications, and set the right expectations. Next this enables the practitioner to develop a schedule and budget that is real and people can support. After all, it is people that must make this plan a reality.

I make reference to the “dimensions” of project scope. This is because scope and boundaries do have dimensions in terms of different views of the project, level of detail and other twist that warrant a separate and distinct perspective on scope. With regard to the actual deliverable, most of the dimensions below should contain a list of items, and each with a “degree of complexity or effort” (high, medium or low).  In the next blog entries, we discuss how this information is used to develop a project schedule and budget.

The Thirteen Dimensions of ERP Project Scope and Boundaries

1) Align scope with project objectives

The fact is most organizations implement ERP for business reasons. Therefore, project objectives (what you want to accomplish) must initially drive project scope, not the other way around. It is never a good idea to proclaim the project will solve all the world’s problems, and at the same time, limit scope to the bare bone necessities to get the software running on the computer. This is where “rapid deployment” strategies get into trouble since they are  designed to limit scope for the sake of time and cost (though outcomes are far from guaranteed).

Furthermore, last minute acts of desperation to cut scope to get back on schedule are usually done without a full understanding of the original objectives that are now compromised. Therefore, if scope is to be cut half-way through the project, objectives and expectations must be realigned with the new reality.

On the other hand, too much scope beyond what is required to achieve objectives (and for the software to function effectively) is not a good thing either. This is usually not a popular philosophy among users, but a necessary one since “scope creep” is inevitable to some degree on any project. Therefore, early on it is important to “condition” managers and users that the system is not intended to be “all things to all people” and expanding scope will not be easy. In fact, once approved, any proposed changes must be business justified and approved by senior management.

2) The Number of “Sites” involved

For the purpose of this discussion, a site is defined as: 1) a physical location, or 2) a logical site. For example, there could be more than one “business unit” at a location, each having its own customer service group using the same software. In “multi-site” scenarios, the scope issues are three fold.

First is the coordination and communication effort required to get and keep all team members, key managers, and users at each site on the same page. Not to mention, I have yet to see any multi-site implementation where a certain amount of politics and finger-pointing between sites did not slow progress. This does impact project effort and how quickly things move along.

It gets worse when the same software module is to be installed in more than one site. In this case, decisions regarding “common” versus “unique” requirements at each site are necessary; and this takes time. This also plays into the decision to treat a given business process at each site, as a single or separate process from a design and set-up perspective. In any event, if the plan is to “reinvent” the wheel for each site, this will increase complexity, schedule, and cost (scope).

Finally, each scope dimension below should be defined at the site level (if the goal is to get a good picture of what the project truly entails).

3) Software Modules

The modules to include in scope drives the overall footprint of project. No doubt, this is one of the first steps in addressing scope. The bad news is when some put a project plan together, the software modules in-scope are one of only a few things considered.

The problem is without further definition, it is difficult to understand what “modules” mean from the standpoint of establishing expectations with users and estimating project duration and budget.

Beyond the fact that modules lack sufficient detail, some modules are more involved than others. For example, anything with the word “advanced” in front of it usually means more complexity, more risk, more time, and more money.

In addition, whether a module implies advanced or not, some modules are  inherently more difficult to implement for most organizations. As an example, the Purchasing module in most packages is usually less of an issue than the Sales Order module. This of course is not universally the case; but level of complexity should not be ignored.

4) Key Features and Functions within each Software Module

This is a lower level of software detail often over looked. Each module has features, functions, and capabilities. It is always best to consider  the capabilities to be utilized right up-front. Otherwise, consultants and the team will waste time and money setting up software functionality that client management has no intention of implementing (or adds little value to the overall objectives). Granted, some discovery may be required to understand the applicability of features and this is never a perfect process. However, this is different then going far down the road spending time on features of marginal value (and no one cares about).

5) Business Processes

The client must identify the business processes to automate. In doing so, one must get into the “sub-process” level. For example, “Procure-To-Pay” is a major business process; but this alone does not tell the story. When we go to the next level, it starts to have meaning.

For example, within this major process, some of the “sub-processes” include: 1) Quotation process, 2) Requisition / Approval process, 3) PO process, 4) PO Receipt process, 5) Invoice / Voucher match process, and 6) Payment process.

6) Business Process “Variants”

All too often people assume a particular “sub-process” (examples above) represent a single workflow. However, in many cases nothing could be further from the truth. A simple example is “receipt of a purchase order”. In most companies, there are many types of purchase orders that are received and transacted very differently (and for good reasons).

As a result, from a scope standpoint each may require unique analysis, system set-up, and testing to the point they should be treated as separate sub-processes (or perhaps children of a sub-process). No matter what we call them, when included they expand scope and must be recognized.

7) Degree of Business Process Redesign anticipated

It is one thing to say a business process is in-scope; but again this is only half the story. This is similar to the complexity factor, but I like to highlight it separately because it can have huge project implications.

For each business process, it begs the following questions:  How convoluted is the current business process? Does it need significant reengineering? Are you planning to implement an entirely new operating philosophy? On the other hand, are you attempting to automate a current process that is well defined and works well today?

There is no right or wrong answer here, but the more one must redesign a process, the more decisions to be made (usually the longest pole in the tent), the more design work to be done, the more emotional it gets, the more issues and unknowns, and the more testing required. There is nothing unusual about any of this, but there is no way around it. When significant process changes are needed, schedule and budget for it accordingly.

8 ) The Number and Complexity of Data Conversions

In scoping conversions, get to the level of understanding the key files in the new software (target system), where the data is coming from (source system or otherwise) and how it is going to get there (manual or automated). Also, do not forget how history records are to be addressed (if at all).

The level of effort comes into play with the following considerations: 1) Source data clean up required prior to converting, 2) The format of key fields in the existing system and the need to get the data into the format of the new software. This includes not only field sizes, etc for important data items, but also how the data is used within the business. 3) The anticipated complexity of the conversion process, program logic required and level of effort to test. 4) Keep in mind, it could be much less time consuming to load data manually versus the alternative of writing conversion programs.

9) The Number and Complexity of Interfaces

This includes interfaces between “other” systems and the new ERP system. The time and cost to design, develop, test and maintain interfaces are almost universally under-estimated. The cost issue includes design and mapping of interfaces, third-party developers or additional “middleware” required (software and hardware). From a quality standpoint, even when thoroughly tested, no interface is fail proof (expect problems at some point).

Therefore, ideally one wants to replace as many legacy systems as possible within each project phase to minimize or eliminate temporary interfaces (that exist only during the transition) and permanent interfaces (to legacy systems deemed outside the final project scope). This tends to be the case even when a few modifications to the new software are required to replace the legacy system.

Expanding the number of modules (to eliminate interfaces) is a trade-off between interface scope and additional module scope. From a user perspective, interfaces are usually assumed the path of least resistance, but often times they later find out this is not the case.

Each interface and the level of complexity should be documented in the project scope. When identifying interfaces, realize there may be more than one interface between two systems (and some going in opposite directions). Therefore, what may initially appear on the surface as a single interface may actually be two or more interfaces.

Do not forget “one-off” databases in the user area that are out-of-scope but linked with the legacy system. They may or may not be supported by the IT department, but nevertheless, can be critical to the business. Also, interfaces to other new third-party software or hardware included in scope must be acknowledged.

It can get worse. Interfaces may force customization to the target or source system to add additional fields and screens to either system (to support the data needs of the other system).

Finally, the complexity issue includes (but not limited to) the frequency of the interface, real-time or batch updates, sequencing and dependencies of data transmissions and data format issues that impact the complexity of interface program logic (similar to data conversions). The question from a user standpoint: Must the users work in both systems (instead of one today)? If so, for how long?

10) The Number of Reports

The number of reports should be estimated since the accumulation of all reports can represent a significant effort. First, get a complete list of reports (from ALL current systems to replace), the distribution list for each, and frequency of usage.

Ask the users to review the list and comment on what reports they “must have” within the new system (wrong, right or indifferent – at this point we are trying to estimate. It is OK if the revised list from the users is full of assumptions) However, this will eliminate many reports that exist today.

Next analyze the list to see if the “must have” reports can be combined, eliminate by standard reports from the new system (or with slight modifications) or the availability of data on-line (or via spreadsheet user downloads) from the new system eliminates the need to write reports. Once this is accomplished the list should be more manageable.

Finally, add a contingency of about 15% to 20% to cover new reports the team or users will eventually asked for once they figure out the additional information available in the system.

11) The Number of End-Users

Whether there are twenty end-users or a thousand end-users, the team still must do all the process and software work for implementation. However, the number of end-users impacts the number of “key users” (subset of the entire population) to be heavily involved. Of course, the more people involved, again, the greater the scope. Not a bad thing, just reality.

The number of end-users also affects the end-user training timeline and resources. During the planning phase, it is necessary to get a handle on training time and resources requirements. Think of this as a rough-cut end-user training plan (not a detail training schedule). Do not wait two months before training to start this planning.

The project team must train end-users as close to go-live as possible. Training more than three or four weeks prior to go-live is a problem since users will not retain what was learned. The more one compresses the timeline to meet this objective the more resources typically required.

This time constraint could drive the need for more trainers since some training sessions may run concurrently. It can also impact the number of facilities, equipment and other resources that otherwise could become bottlenecks. Therefore, one must consider the trainers and resources now in order to get the right people involved early on, estimate a duration for end-user training in the schedule and to properly budget for it.

12) Software Customizations or Enhancements

Most know by now software “mods” (customizations or enhancements) increase risk, time, cost, and can negatively impact software quality. Therefore, eliminating or keeping them to an absolute minimum is always recommended. However, in the real world organizations make mods and often for very good reasons. The question is: How do you handle them during the scoping and planning phase of the project?

Here is the answer. After evaluating software, when there are strong perceptions mods are required, do NOT automatically include them in the project scope unless ALL of the following apply:

A.    Software limitation is verified

Early testing / verification (immediately after the software evalution) has been performed to confirm the software limitations exposed during the evaluation.

B.    Functionality is linked to key project objectives

The proposed mod is deemed by management as critical to the success of the project.

C.  It is understood what is required and how the mod is to be made.

The mod is defined in terms of specific functionality, external design attributes(screens and logic) and how the mod will be accomplished from an internal design standpoint. Internal design means: Are we proposing outright “customizations” to existing programs and tables? Or changes through more external “enhancements” that integrate with the system while attempting to minimize the impact on existing programs and tables? (for the sake of future upgrades).

D.   The Mod is “pre-approved” for scope planning purposes only    

Management has “pre-approved” the mod with a full understanding of alternative solutions and project impact (extra time and cost). Pre-approval means the mod is recognized as “in-scope” and included in the schedule and budget, but NO coding is allowed to proceed as this point.

E.    There really are no other viable solutions

The need for the mod is tested and verified again during the prototyping phased (usually following project team training and runs currently with current process analysis). The reason is, regardless of the original perceptions, once the team learns more about the software and looks closer at different ways of doing business, a proposed mod may not be required after all.

F.  Final Approval

After prototyping, if a mod is still deemed necessary, estimates are revised and present to management for a final approval. Afterwards,  the scope, schedule and budget are revised accordingly and the modifications can now proceed.

Get a Jump Start on Modifications Discovered Early On – They are on the Critical Path

Disposition of proposed modifications discovered during the software evaluation process must occur before the “official” design phase of the project . This allows for an “early start” in programming the modifications. The balancing act to consider is while any proposed mod must be understood and justified (with due diligence), waiting too long to start coding can put the schedule at risk. Always remember, most mods are on the “critical path” within the project schedule.

Other Potential Modification Scenarios

In the situation where some mods are expected, but none are yet defined or approved, it is a good idea to build some reasonable “contingency” in the schedule for good measure(even though senior management must later approve any mod and the project schedule is revised accordingly).

When there is a “no modifications allowed” policy proclaimed by senior management, do not plan for any. If mods are later proposed, they must be approved by senior management. In this case, the decision to expand scope rest with senior management, not the project manager.

13) Boundaries (what is out-of-scope?)

For all dimensions of scope discussed above, it is always best to go back and document what is “out-of-scope”. This more clearly establishes the project boundaries. The reason is people sometimes “hear what they want to hear”, and make assumptions on their own about what “in-scope” means.

We have all been there before when the manufacturing manager says (for example): “Steve, I thought shop floor control included wireless data collection!”  Response: “Sorry Joe, that is not what we meant.”  The point is, “in-scope” states what is included, but it only implies what is not include.  Why not state the out-of-scope items up-front to avoid confusion or prevent someone from attempting to slide it in the back door later?

The problem is even though the project manager may “win” this particular scope issue, he or she may actually lose in the long run when Joe no longer supports the project. It is better to get Joe on board with the decision early on or recognize it as in-scope before we put the ball into play.

Conclusion

The “Scope and Boundaries” document is a key deliverable within the “scoping and planning” phase and is completed before the project schedule and budget are finalized and the project is officially launched.

The scope document is the responsibility of internal project manager, with the help and guidance of the consulting project manager. It requires the participation of the executive steering team, executive sponsor,  project team, application consultants, key managers (process owners) and some knowledgeable and influential end-users. Though many are involved and provide valuable input, scope must be managed very closely, and tough decisions are usually required by the project manager and senior management.

The final version of the scope deliverable is next presented to all the above as a last review. Depending on how formal the organization, it is  signed-off by the executive steering team. Now, as a project manager, you have something valid to serve as input into scheduling, budgeting and later controlling  the project. 

http://it.toolbox.com/blogs/street-smart-erp




Popular Searches:


  • how might the project team recommending an erp design strategy justify its recommendation as compared with other types of design strategies?

Related Posts:

Striving for a Customer Focused Approach to Innovation 1 of 3

March 26th, 2010 by

depths of innovation




If your company does any kind of innovation, how would you describe it?


  • Stoic – slow, plodding, methodical, and generally consisting of small incremental improvements (minimalist).
  • Stretch – Evaluation of current as well as future needs and wants of the customer with some structured framework for achieving a future state (striving).
  • Maelstrom – creative “free for all,” sky’s the limit and a “no holds barred” barrage of brainstorming and chaos (directionless).


The Common Approach to Innovation, Generally Stoic or Maelstrom

There are generally two separations around innovation in practice. 

 1)      There is the “continuous improvement” type of “innovation” which is incremental or stoic.

2)      There is the complete “free for all” type of “innovation” that relies more on being creative for creativity sake and tends to be a chaotic maelstrom.

Think about it, improvement, creativity, and innovation are distinct words with different meanings even though each can include components of the other.  Innovation generally requires application of the creative process, not just the creative process in a vacuum, and it requires the incremental process of improvement.  Therefore I am proposing an approach to innovation that uses an innovation narrative and early prototyping to achieve new products or services with limited risk and cost.

Stoic Innovation (This is Really Continuous Improvement)

A number of product oriented companies rely heavily on the “stoic” method to innovation.  They make incremental design or usability changes to existing products and product lines.  This approach has some merit as it is generally risk averse and has application in mature markets, commodities, or areas where there is little competition.

This approach is best seen in many auto manufacturers in between major model overhauls.  They will make incremental changes and improvements to an existing model for roughly 8 – 10 years and then make a complete departure with a new platform or model.

Innovation Maelstrom (Much Ado About Creative Chaos)

Some academic institutions, several Fortune 1000 companies, and those who buy into unscrupulous consulting models that promote blue sky approaches to design or innovation generally adopt the maelstrom approach.  Although this approach is capable of producing “blockbusters” it is very high risk, very expensive, and has little application outside of training exercises and academia.  Those “blockbusters” that are produced are rarer than winning massive lotteries.  The underlying problem with this approach (as anything other than a training exercise) is the deliberate disconnection of brainstorming and the creative process from constraints or limitations. 

While the creative juices may flow, and even a few truly breakthrough innovations, inventions, or novel approaches may emerge, the results are rarely (if ever) cost effective.  They are usually preceded by huge budget expenditures and string after string of “oddities” that have little or no useful application.  Here are a few blockbuster examples of innovative design work that eventually paid off, but not until mountains of money was spent to devise and develop useful applications.

Look at the laser, invented in Bell Labs which took some 20+ years to find commercial uses for it.  Or what about the original IBM tube based computer, commercial application took nearly 30+ years to begin to gain widespread business acceptance.  What this points out is that innovation for innovation sake is not a productive or cost effective use of a company’s limited resources.  And although both the laser and the computer had dramatic, life altering impacts later on, it took many years to realize the benefits and massive amounts of expenditures.  Neither of these innovations was very effective before another invention – the transistor – was able to animate them and allow for any practical productive use.

Stretch Innovation (Striving for a Future State)

The third approach, which I personally consider the most balanced of the three between achieving great results without too much risk, and without too much cost would be the “stretch.”  This approach relies heavily on the relentless pursuit of an idea or ideal.  But to bring the idea or ideal to life it relies heavily on the ability to draw key information out of your customers, or from the marketplace, and then create a special “narrative” about the new state of the product or service.  Think of it like an ideal state elevation, rather than a full blown blueprint, but committed to writing.  Just like the artist’s rendering, or the architect’s elevation does not include all of the construction details, a good narrative of the future state should produce something that people can picture and work toward.

Related Posts: