2. INTRODUCTION
Budgeting for a SAP project is a menace. Estimation techniques are cumbersome and takes round of
table chairs and stakeholders to decide budget for a SAP Project.
Most of us follow a usual sequential approach for implementation of SAP Project, better called as
waterfall model.
Fig. Waterfall model for Software Project.
Even blueprinting phase doesn’t seal requirements of the project. The BDUF (Big Design Up Front)
blueprint approach attempts to identify all possible scope and design details for a project.
Once development begins, the directive to the project is to deliver all scope identified during blueprint.
This means that if the budget cap is reached before all development is done, the project has no choice
but to ask for more funds.
Revisiting blueprinting in realizing phase is a normal process these days by clients which they then at
realization phase understand that what they have signed off past back some months before, would not
going to be enough to fit in their business processes because of difference in requirements or change in
understanding of steering team when they (requirements) were captured and when they were realized.
At this point, the team, for all purposes, must return to the blueprinting process,recapture requirements,
redesign, and reconfigure or redevelop the solution. Change requests are issued for additional funds,
and the result is an extension of budget and schedule.
3. SAP Projects are the BIG THING these days for clients and consulting partner because the resources
associated are niche and funds involved are huge. Good will for the consulting partner is vast. For this
reason, traditional projects have a huge management overhead to take care of the burden of continual
planning and status monitoring.
Agile considers management overhead to be one of the largest sources of waste on a project. Since the
sources are niche but they follow BDUF (Big Design Up Front) they are unable to meet the deadline the
schedules, which causes finger pointing occurs between the delivery core and the management
overheads.
Given that projects often run late, the team ends up having to multitask which further increases project
stress.
Agile Methodology on the other hand bypasses all these menaces for SAP Project because new
requirements locked during realization go for an iterative loop and enhance delivery executive decision
making mechanism.
Using 80/20, and an assessment of value delivered to date, they can make decisions at checkpoints
throughout the project, to decide where to continue spending. If schedule issues are encountered, an
Agile approach allows us to deliver higher value items within budget.
Compare Agile to waterfall where there is an irreversible approach which doesn’t looks for enhancing the
prior phases even when there are business requirements. Agile gives a spiral approach to the whole
delivery which is much better approach for clients.
Although this locking in effect of waterfall can be useful in the short term to maintain sales in a vendor
implementation, it can damage the potential for long term sales.
Given that SAP customers are continually adding modules and upgrading, a long term customer loyalty
approach is more likely to gain repeat business.
4. SCRUM AND KANBAN
Following would be an overview for SCRUM and KANBAN. Each have a considerable different base
elements but both the end is the same effects. Different paths to same destination.
Scrum
Scrum was developed by Jeff Sutherland and Ken Schwaber in the early 1990s. It is an approach that
most readers will be familiar with, because it uses time boxed iterations. Scrum calls its iterations,
“sprints,” and the goal of each sprint is to build a tested, workable piece of the system, that is ready to be
released to production.
Figure: Scrum sprints
Scrum uses what is called a “product backlog,” to collect requirements and manage the scope. Each
sprint builds a selected set of items from the backlog.
There is a KPI expert sitting around and the end of every Sprint he collects the backlog collected after
realization and prioritize discuss it with other Key Persons and align then in a queue of being delivered.
At the starting of every sprint Key Person dictates requirements to every team involved and define the
preferred list of objectives to the duration of sprint.
Sprint starts with a kick off team meeting. The team then negotiates the sprint scope, based on their
estimates. A conversation then ensues where the team gains a high level understanding of the selected
backlog items, and creates an initial draft of the tasks required to complete each selected item.
5. A unique aspect of Scrum is its approach to teams. There are no “unique” roles in Scrum, other than
developer, Scrum Master and Process owner (KPI Expert).
Scrummaster isthe rule expert for the team make theteam understandthe rulesofthe project andclears
all the encumbrances the duration of sprint. The Process Owner is responsible for defining the project
vision, deliverables and priorities.
Other than the ScrumMaster and process owner, all other team members are referred to as
“developers.” The reasonbehindthisistomaximize collaborationwithintheteam.Theobjectiveofevery
team member to do every task assigned to him.
This means that any one person should be able to perform requirements and design analysis, code,
configure, test and write documentation. This generalization causes issues in the specialized world of
SAP configuration.
“Smaller Team perform much better under this Agile methodology” -- Scrum Experts Says.
The study found that a “five to seven person team will complete an equivalently sized project in the
shortest amount of time.” Jeff Sutherland writes that the “team in Scrum
is seven, plus or minus two people” (Scrum Handbook). Due to the smaller team size, Scrum has a
method of coordinating projects of larger sizes and refers to this as a “Scrum of Scrums.
A Scrum of Scrums involves Scrum Masters from each team meeting to coordinate work between the
teams. In the Scrum of Scrum approach, planning must include careful consideration of
dependencies between the teams, to help ensure that each team can proceed independently on their
work asmuchaspossible. Scrumbelieves that onlyhistoricalperformance, or velocity,is a valid predictor
of future performance.
6. Kanban
Kanban has its origins in lean, and just in time, manufacturing processes. Japanese, the term Kanban
refers to a “signal card”. Signal Card for a process owner (or an upstream process) means that
(Manufacturing process) needs the raw material or service and process is signaling that it is going low on
this object.
Figure: Kanban in SAP SDLC
No new procurement or a new process is initiated till the signal card is raised which says you can initiate
the process to fill the vaccum created consumption pf a raw material or service.
Kanban was developed as a mechanism to help control scheduling of the work needed to produce a
product. It serves a number of key purposes which center around visualizing work, so that producers
know what needs to be produced, when it needs to be produced, and how much to produce.
David Anderson took Kanban principles and applied them to software
produc- tion (Kanban: Successful Evolutionary Change for Your Technology Business). He found that the
core principlesofKanban served wellto help addressissues of waterfallsoftwareproduction. Specifically,
Anderson was able to define a Kanban approach to software that allows its users to improve throughput
and reduce leadtime.
On a software project this is revealed in lower quality work, and an increase in unfinished work.
Kanban addresses this issue by recommending we define Work In Progress (WIP) limits for each of our
work item types.
7. Project Manager try reduce the lead time. Lead is just like delivering the first quantum of deliverables
according to the scope of the project. “From starting a feature to completing it”.
By increasing throughput, the project is able to get more work done in a given time period. By decreasing
leadtime, the project is able to more quickly deliver value to the customer. Anderson recommends a
number of lean techniques to improve throughput and leadtime. These include, for example, reducing
multi- tasking, addressing bottlenecks and roadblocks, and reducing waste.
Multitasking literally means the simultaneous execution of more than one program or task by a single
person. This puts down the quality of the delivery of tasks for sure because you again start to do
sequential work in a round robin way. Multitasking is a good way to do many things poorly.
Project managers or Process owners bloat team with tasks which causes poor quality in delivery. They
try to pretend that the team has more capacity than it truly has.
Once we start that method of working, it spirals, and we find that we can never catch up, because the
team ends up with a stack of items in process that never seem to move to “done.”
On a software project this is revealed in lower quality work, and an increase in unfinished work.
Kanban addresses this issue by recommending we define Work In Progress (WIP) limits for each of our
work item types. A Kanban board visually shows how much work is in progress, and gives us a simple
checking mechanism to ensure that the WIP limits are respected.
These concepts further give rise to SLA and other agreements and penalties if WIP limits are not
respected.
The project’s job at that point is to identify methods to relieve the bottleneck. Methods can include, for
example, improving our upstream processes to ensure that work arrives in a “ready to work on” state
at the bottleneck point. If our bottleneck is a programmer, then we will want to ensure, for example, that
test specifications are in a good finished state, so that the programmer does not require as much back
and forth communication with the analyst. Another method is to redesign the work, so that the
bottleneck does not have as much work on their plate.
Dependencies are the reason for bottleneck. If a process is in a wait state and is required for some context
of other process to complete and then start its execution this is the biggest bottleneck.
8. In other words upstream processes are waiting for the signal card to get issued from the downstream
processes to move ahead. The Kanban board can be used to quickly highlight these blocks and focus the
team’s efforts on working to resolve the block.
The structure of a Kanban board helps us communicate priorities to the team. The Kanban board begins
with an input queue. The input queue should be loaded with just enough work from the product backlog
to keep the team busy.
Figure: Kanban board
Kanban uses five core properties to improve software development:
• Visualize workflow
• Limit work in progress
• Measure and manage flow
• Make process policies explicit
• Use models to recognize improvement opportunities (Kanban: Successful Evolutionary Change for Yo
ur Technology Business).
9. Figure: Kanban meshed with CMMI
As in Scrum, Kanban believes that historical performance is your best predictor of future performance.
In Kanban, one can use throughput, a measure of completed work items per time period, and leadtime,
a measure of the duration it takes to complete a work item, to predict the time it will take to
complete future work items.
