As we think of Project Management in modern business environment, we think of processes, resources, tasks, and all 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 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 tool, and create weapon. However, only a few tools must be used at a time, otherwise you will overwhelm client, and your project staff.
One must always keep in mind that as a Project Manager your primary duty is to bring project in on time, and on budget. The operative word is to try, as we all know that above objectives are considered in realms of fiction in certain Project Management circles. But trying, and its precursor, intention of bringing 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 project staff.
Many people are slightly taken aback by 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 EPM two steps ahead at all times of everybody else.
Change Control
Our first and 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 steady addition of requirements, which were not stated originally.
The process of Change Control starts with person making change. This person is usually on business side (or whichever side that owns/initiates project). The change initiator fills out a form, which is passed along to team lead of module/function being affected. Once change seems technologically feasible and makes business sense, it is passed along to project manager. At this point, team lead and Project Manager decide how much time should be added to project, or how much money should be added to budget to add necessary resources (or both).
Once this decision is made, project manager signs form and form is forwarded to person, who originally initiated change. The originator’s department then approves increase in resources, and change is created, by assigning it a control number.
There are some documents that power Change Control. The first is Change Control Form, which is created in MS Word. The form must have enough entries to identify change in detail, possible impact on technological and business sides, and spaces for remarks and signatures. The second piece of document is Change Control Tracking Database, which is created in MS Access. The database mirrors 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 Issue list. The Issue list is basically made up of defect that can be put aside for further discussion between stakeholders and EPM, for a latter date. Usually, non-critical defects, which do not make Change Control list, end up in Issue Control.
Similar to Change Control, Issue Control must be managed professionally by EPM. The two documents needed for proper Issue Control are Issue Control Form, and Issue Tracking Database. The rite of passage to Issue Control is a bit different. The decision is usually made between EPM and stakeholder and Issue is moved to Issue Control.