|
Project_Manager_Armaments
| Project Manager Armaments
As we think of Project Management in the modern business
environment, we think of processes, resources, tasks, and all
the common sense needs of Project Management. Armaments are a
far cry. After all, armaments are made for killing or cleaving.
For Project Management, you can use armaments. You can kill with
them, use them to help people, and you can manipulate situations
with them. Nonetheless, there is a limit on what the Extreme
Project Manager (EPM) can carry.
Do not confuse armaments with tools. A weapon is used to contend
against an opponent. A tool is used to complete a task. For
example, Microsoft Project is a tool, while Change Control is a
weapon. The EPM will use the tool, and create the weapon.
However, only a few tools must be used at a time, otherwise you
will overwhelm the client, and your project staff.
One must always keep in mind that as a Project Manager your
primary duty is to bring the project in on time, and on budget.
The operative word is to try, as we all know that the above
objectives are considered in the realms of fiction in certain
Project Management circles. But trying, and its precursor, the
intention of bringing the project in time, certainly goes a long
way in actually realizing those goals.
For example, Change Control requires forms to be filled out,
information to be channeled interdepartmentally, control numbers
to be assigned, scope creep data to be managed and tracked, and
so forth. In other words, each weapon that you create will
generate some extra work for the project staff.
Many people are slightly taken aback by the confrontational
nature of Extreme Project Management. It really is not
confrontational at all. In fact, it is designed to avoid
confrontations before it is realized. It keeps the EPM two steps
ahead at all times of everybody else.
Change Control
Our first and the most important weapon is Change Control. We
will start with Change Management, as I am always fighting about
it in virtually every project that I do. In Change Control, our
primary objective is to combat scope creep. Scope creep is the
steady addition of requirements, which were not stated
originally.
The process of Change Control starts with the person making the
change. This person is usually on the business side (or
whichever side that owns/initiates the project). The change
initiator fills out a form, which is passed along to the team
lead of the module/function being affected. Once the change
seems technologically feasible and makes business sense, it is
passed along to the project manager. At this point, the team
lead and Project Manager decide how much time should be added to
the project, or how much money should be added to the budget to
add the necessary resources (or both).
Once this decision is made, the project manager signs the form
and the form is forwarded to the person, who originally
initiated the change. The originator’s department then approves
the increase in the resources, and the change is created, by
assigning it a control number.
There are some documents that power Change Control. The first is
the Change Control Form, which is created in MS Word. The form
must have enough entries to identify the change in detail, the
possible impact on the technological and the business sides, and
spaces for remarks and signatures. The second piece of document
is the Change Control Tracking Database, which is created in MS
Access. The database mirrors the Ms Word form exactly. The
database is updated every time a control number is assigned.
Issue Control
Issue Control is a bit simpler then Change Control. The Issue
Control is charged primarily with the Issue list. The Issue list
is basically made up of defect that can be put aside for further
discussion between the stakeholders and the EPM, for a latter
date. Usually, non-critical defects, which do not make the
Change Control list, end up in Issue Control.
Similar to the Change Control, Issue Control must be managed
professionally by the EPM. The two documents needed for proper
Issue Control are the Issue Control Form, and the Issue Tracking
Database. The rite of passage to Issue Control is a bit
different. The decision is usually made between the EPM and the
stakeholder and the Issue is moved to Issue Control.
It is recommended that the forms and the tracking styles are
purposely made different to avoid confusion, as a lot of
information in the forms and the tracking databases may seem
similar. Also, the numbering system in Issue Control is slightly
different. Whenever a defect is not fixed, and moved off to a
“holding area” somewhere, the stakeholders get a little nervous
about the future of that defect. Because of this reason, the
Issue number is the same as the Defect Number. This is done to
avoid ‘misplacing’ any defects.
Cloud Surprise
Okay, I am going to push the envelope a bit here. This is where
we become “extreme” and sometimes get into a tiff. But it is
worth it. Cloud Surprise is a weapon that is more psychological
then functional. But it is incredibly effective every time it is
used.
Cloud Surprise is a pretense, which is unleashed on the victim
to dampened bad news, amplify good news, or simply to color dull
news.
It will be interesting to declare how I came up with the term,
Cloud Surprise. Then you will understand the reason for its
existence.
A few years ago, I used to fly with a friend of mine, who was
quite a daring pilot. Although I avoid roller coasters, I am
quite an excitement junkie, when it comes to flying. Cloud
Surprise basically entailed us flying straight into the clouds
from the bottom, till we broke free on the other side… All of a
sudden being blinded by the bright sunlight; or, sharply diving
from the top till we broke out from the clouds, and saw the
ground approaching at a high speed, to fill our view inside the
cockpit.
Although we knew exactly what lied on the other side, it was
kind of a surprise to see the bright sunshine, or the
approaching ground. We were so engrossed in speeding through the
clouds, and having a strong feeling of anxiety and apprehension
that our knowledge of what lied on the other side was
temporarily forgotten: hence, the name Cloud Surprise.
I use this weapon when I have to deliver news, which the staff
is expecting, but not necessary with great anticipation. For
example, when I have to inform the IT staff that they will have
to work on New Year’s Eve to monitor the network, I would first
indicate to them that they may all have to work a 12 hour shift,
maybe even 16. I usually qualify this statement by adding a bit
of detail to it, such as advising them to wear comfortable
clothes, and to charge their cell phones. Then a few hours
before the shift, I will proclaim that they only, in fact, have
to be there for a four-hour period, just to monitor the change
of date. This is usually met with cheers of appreciation! Get
the idea? Cloud Surprise!
Counter-surveillance
Keep your ears open. There is no need to actually spy on your
coworkers. An EPM keeps all issues at a high level, delegating
authority to the appropriate staff members. Hence, small details
should be left to the team leads. However, it does not hurt to
be informed. If you spot two people, who are sensitive to your
project, having a conversion, casually walk within earshot, and
do some simple task, like tying your shoelaces, or pretending to
have a conversation with another coworker.
Keep your eyes open too. Carefully check out everything that
goes within your range of vision. Documents are very powerful.
Many companies go to great lengths to ensure that the right
people look at the right things. For example, Motorola has a
whole methodology on how statuses are assigned to the documents
in the hierarchy of privacy, and how the employees handle those
documents.
In general, be aware of everything that goes around you in the
organization. This may seem like a frivolous advice. But by
trying a bit harder and practicing surveillance techniques, you
will have a fantastic advantage over the rest of the managers.
The use of some of these armaments may sound a bit draconian,
but they work. Always remember, the final objective of an EPM is
the greatness of the project.
About the author:
Shaun H. Ajani is the author of books "Extreme Project
Management" and “Life Wizard – Advance Life Management". His
book, “Soul Management – Magic of Reality” is in the works. He
has been published in many national and international magazines.
Shaun has worked with aviation, IT, retail, HR, finance,
education, and training industries, in companies like Motorola,
Washington Mutual, Boise Cascade, and Sears. Shaun Ajani
consults as a Certified Project Manager in Chicago at Spherion.
|
|
| |
| |
