This Static Spot is open for sponsor

Click Here to Sponsor MCT Eric Post in Full Page

Afrikaans Afrikaans Albanian Albanian Amharic Amharic Arabic Arabic Armenian Armenian Azerbaijani Azerbaijani Basque Basque Belarusian Belarusian Bengali Bengali Bosnian Bosnian Bulgarian Bulgarian Catalan Catalan Cebuano Cebuano Chichewa Chichewa Chinese (Simplified) Chinese (Simplified) Chinese (Traditional) Chinese (Traditional) Corsican Corsican Croatian Croatian Czech Czech Danish Danish Dutch Dutch English English Esperanto Esperanto Estonian Estonian Filipino Filipino Finnish Finnish French French Frisian Frisian Galician Galician Georgian Georgian German German Greek Greek Gujarati Gujarati Haitian Creole Haitian Creole Hausa Hausa Hawaiian Hawaiian Hebrew Hebrew Hindi Hindi Hmong Hmong Hungarian Hungarian Icelandic Icelandic Igbo Igbo Indonesian Indonesian Irish Irish Italian Italian Japanese Japanese Javanese Javanese Kannada Kannada Kazakh Kazakh Khmer Khmer Korean Korean Kurdish (Kurmanji) Kurdish (Kurmanji) Kyrgyz Kyrgyz Lao Lao Latin Latin Latvian Latvian Lithuanian Lithuanian Luxembourgish Luxembourgish Macedonian Macedonian Malagasy Malagasy Malay Malay Malayalam Malayalam Maltese Maltese Maori Maori Marathi Marathi Mongolian Mongolian Myanmar (Burmese) Myanmar (Burmese) Nepali Nepali Norwegian Norwegian Pashto Pashto Persian Persian Polish Polish Portuguese Portuguese Punjabi Punjabi Romanian Romanian Russian Russian Samoan Samoan Scottish Gaelic Scottish Gaelic Serbian Serbian Sesotho Sesotho Shona Shona Sindhi Sindhi Sinhala Sinhala Slovak Slovak Slovenian Slovenian Somali Somali Spanish Spanish Sundanese Sundanese Swahili Swahili Swedish Swedish Tajik Tajik Tamil Tamil Telugu Telugu Thai Thai Turkish Turkish Ukrainian Ukrainian Urdu Urdu Uzbek Uzbek Vietnamese Vietnamese Welsh Welsh Xhosa Xhosa Yiddish Yiddish Yoruba Yoruba Zulu Zulu

 

 

Article Navigation

Back To Main Page

 

Click Here for more articles
Google
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.

 


©2005 - All Rights Reserved

This Static Spot is open for sponsor

JV Blogs Visit free hit counter