|
Click Here
for more articles
|
|
|
|
Project
Manager - Armaments
|
|
by:
Shaun H. Ajani
|
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.
|
|
