Project Management
|
 |
|
| Project
Management at BatchMaster is based on the
global standards of PMI® and PMBOK®. The methodology
has been derived after many years of research
and experience, and incorporates the 9 Knowledge
areas and 42 processes as detailed in PMBOK®.
For sake of simplicity, and co-ordination
with customer’s project team, the methodology
is made in simple, easy to understand and
adopt terminology. At BatchMaster, we dwell
upon following stages for successful completion
of an ERP implementation project. |
|
|
Developing a
Project Plan |
|
|
| The BatchMaster
Project Plan sets out the roadmap for progressing the
project – which steps need to be followed and how they
should be followed. A good plan means that all stakeholders
involved in the project can refer to the plan and understand
their responsibilities, as well as the other project interactions
requiring their involvement. This is a working plan so
all inputs are taken from the customer and the project
team before the Project Manager actually drafts one. |
Estimating Guidelines |
|
|
| In creating
an estimate, BatchMaster Project Managers consult the
entire project team and different departments of the customer.
We ensure that national holidays and known staff leave
have all been allowed for in the estimate. We rely on
a standard calendar which means that calculations are
consistently based on: a standard working week, a standard
effective workday; a standard work-month. Despite the
variations in months, usually 18-20 effective workdays
per month are utilized. Additionally, BatchMaster identifies
that resources have the correct mix and level of skills
needed to be able to perform the project tasks. |
Scope Creep |
|
|
| Probably,
the most dreaded cause of project failure is scope creep
– bits and pieces being added into the project scope
without due assessment of their value or impact on the
project’s capability to deliver. BatchMaster is
aware of scope creep, we manage it and control it. However,
each extra item added into the project scope compounds
the complexity of the project. There is no denying that
changes are very likely to be requested during a project.
All changes can be made with some impact to the project.
Changes can be made as long as the impact and risk to
the project are fully understood by the stakeholders,
the team, the Steering Committee and the Project Sponsor.
An effective Change Management process is used by BatchMaster
Services. |
Risk Management |
|
|
| There are
risks in everything we do. Managing BatchMaster ERP projects
is no exception.There will always be some events that
pose a threat to any project. The extent of the impact
if those risk events do occur depends on planning and
preparation. Risks are identified, assessed, mitigated
and, if the event does occur, managed through to resolution.
Planning for risks means that potential actions can be
prepared well beforehand when there is time to do so.
|
| Risk mitigation
is the reduction or elimination of the impact of a risk
event on a project. In planning for the occurrence of
a particular risk event, the BatchMaster has a number
of options available. For any specific risk, you could
accept the risk, transfer the risk, control the risk or,
avoid the risk. Project Manager maintains a Risk Register
to record risks for a project. |
Issues Management |
|
|
| Just as there
are risks in projects, there are events that happen from
time to time for which the project team didn’t envisage
or make plans. These are issues. They too need to be monitored
and managed so that the impact on a project, if any, is
kept low. What if a risk event actually happens? Well,
these now become issues affecting the project and, like
any other technical issue, need to be managed through
to resolution. Anything can be an issue. Issues can include
loss of resources, delays to the completion of an installation,
being behind schedule or under budget, and so on. Issues
are managed via an Issue Tracker. |
Project Change
Control |
|
|
| Situations
change – it’s a fact of life. So, during the
time of a project, there will also be changes. Some changes
will be small, such as the addition of extra training
sessions. On the other hand, some changes can be very
significant. Changes with high impact include moving the
solution design in-house with the external vendor going
into liquidation and scaling down the scope of implementation
after an organizational restructure. Managing project
changes needs to be pragmatic. Changes that affect the
project budget, schedule or its capability to deliver
the intended output should be administered carefully.
Changing any of these is not the end of the world! Having
a process available for handling changes means they can
be done in a controlled and planned manner. Proposed changes
need to be captured, assessed and then applied if required.
|
Document Control |
|
|
| Have you ever
attended a project meeting where the Project Manager,
members of the project team and key stakeholders were
referring to different versions of the same project document?
A mess can eventuate very quickly, with everyone’s
time wasted and patience stretched. Keeping control of
documents is not difficult, yet it is surprising how many
projects exercise no form of version control. |
Managing Document
Changes and Distribution |
|
|
| In controlling
and identifying the versions of documents, the following
is a simple method BatchMaster use. The version number
and release date of each document is indicated on the
cover page and in the document naming convention. Additionally
for every document, include the version number in the
footer of each page. |
Quality Management
- Stage Gate Reviews |
|
|
| Each stage
in the StageGate® process includes a set of prescribed
and cross-department activities, incorporating industry
best practices. The activities during a stage are carried
out in parallel, not in sequence. This is to ensure that
they are executed quickly and effectively. |
| Gates are the
points in the project lifecycle where the gatekeepers
make a decision. The possible decisions are Go,
Kill, Hold, or Recycle. The gates are also: checkpoints
for controlling the quality of the project: Has the team
done a quality job - is the information from them sufficiently
valid to make a go/kill decision? Has the project team
done its job well? Is the project still attractive from
an economic and business standpoint? Are the action plan
and the path forward sound? The gate meeting concludes
with a clear and fact-based decision. If the decision
is Go, the gatekeepers commit the necessary resources
and visible support the project team. |
