What is Project Management
A project, on the other hand, is a temporary undertaking with a specifically defined goal. The key word in that definition is the goal. If the goal is not defined, approved, and published, the project is guaranteed never to succeed.
Without a defined goal, a project will become a Christmas tree, where everyone who wants anything will hang their particular ornament. In the world of project management, this is known as scope creep.
The other key in the definition of a project is that it is temporary, with a well-defined beginning and end. Because we are working toward a concrete goal that goal will be accomplished, and the project will end.
When running a project, the overall goal has to be divided up into bite-sized tasks. These tasks are assigned to a team or an individual for completion. We also map out the dependency relationships between the tasks (i.e., which tasks are dependent on the outcome of a previous task).
Understanding the dependency relationships between the tasks and the resources needed for each task is the key to drawing up budgets for the money and time needed for the project.
What makes a project different from a task is that a project requires resources from several different people or groups. Coordinating these requirements is what a project manager does.
This blog discusses many tools that are at the disposal of a project manager. Keep in mind that these tools are only useful as far as they help to achieve project goals.
You can spend all your time fiddling spreadsheets without having a positive impact on the project. Everything you do needs to move the project closer to completion.
Note Project management is a much bigger topic than we can cover in one blog. Please check into some of the references at the end of the blog for a more complete view.
A project’s size, usually known as its scope, has to be set as a defined, reasonable objective. A published scope, with measurable objectives, is the key to managing expectations of the people who depend on the project.
Project expectations are governed by the constraints of project management:
Capability. The number and size of the deliverables in the project objective.
Time. How long (in calendar time) it will take to complete the project scope.
Cost. This includes both monetary costs as well as indirect costs (such as staff time or other resources).
Quality. How reliable and robust the system is.
Part of defining a project’s scope is identifying which of the constraints is the highest priority for the project’s sponsor. You can’t have a project be cheap and fast and still have it be feature rich. There is a balancing point in there somewhere that meets the needs of the organization.
Project management is not quite that simple. Drawing up and agreeing to the project objectives is a process all by itself. We try to maximize the project’s usefulness by negotiating with the different stakeholders in the project.
Here are several roles that are important when setting up a project:
Project Champion This person is someone high in the organization who is a key proponent of the project. Strong commitment to a project by a champion is a good predictor of project success. A champion can help corral needed approvals, resources, and attention to move a project along.
Project Sponsor This person provides the leadership and political juice to move the project forward. The project sponsor will provide the funding and have the ultimate say in the direction of the project.
Project Manager This person coordinates the work involved in the project and makes sure that the project milestones are being achieved within time and budget constraints.
Project Team Project tasks are assigned to different members of the project team.
Stakeholders. Stakeholders are the people who have an interest in the project. This includes customers and implementers of the project, as well as those funding it.
The stakeholder community will have different interests. One of the challenges a project manager faces is balancing the different demands of the stakeholder community.
Part of the nature of projects is that they have distinct phases.
Concept. This is the phase where an idea is crystallized with preliminary estimates and feasibility studies. This phase should include preliminary timelines and cost estimates based on the agreed project scope.
Development. In this phase, the project plan is developed and improved. The task list should be detailed thoroughly, and a budgetary cost estimate should be approved.
Implementation. In this phase, the project is executed according to the plan. Progress is measured and tracked, and stakeholders are kept in the loop.
Closeout. Once the implementation work is completed, the customer needs to accept the work. Postmortem sessions and reports should also be completed in this phase.
Iterative models are often timeboxed, meaning that the cycles have a defined length, usually only a few weeks.
There are several advantages to an iterative model
Progress is tangible and visible to the business unit. It provides a natural way to deal with evolving requirements as business needs change.
Timeboxing provides a constant incentive to the development teams to produce.
The most important functionality is usually delivered first. If the project runs out of time or resources, some business value will still have been provided before the project’s end.
There also are some disadvantages
The structure of an iterative cycle can be used to excuse a failure to plan or architect properly.
Discipline is needed to close out a project rather than allowing it to cycle endlessly.
Regardless of the approach, one of the best predictors of project success is if an organization follows a consistent process for initiating, reviewing, and executing projects.
Failed projects can be hugely expensive for the organization. Having concrete phases and gate procedures is part of having a robust project management process to focus resources on business priorities.
The project has to be defined. This includes defining the size of the project, as well as what the success criteria will be. Usually, a business case is drafted to justify the project’s costs.
Part of defining the scope is identifying all the key stakeholders. The stakeholders must agree to the scope prior to beginning, and changes to the scope have to be accompanied with the resources to make those changes.
The initial scope of the project is defined and published in a document known as a project charter. The charter must be accepted by the key stakeholders; if a stakeholder is not on board that person or group may actively or inadvertently sabotage the project.
In many cases, it is best to finish the project with a limited scope, and then add features or functionality as part of a follow-up project. If a project manager does not control scope creep, the project is doomed to meander about and eventually fail when patience and resources are exhausted.
A business case is exactly what it sounds like. It is a case made for management to secure the resources needed to pursue the project. A typical business case includes several elements:
Business objective. What problem is being resolved by this project?
Current situation. This may be presented in a SWOT format (Strengths, Weaknesses, Opportunities, and Threats).
Options. Alternative ways of attacking the problem.
Recommendation. Which one is preferred by the technical community? Why?
Project requirements. What resources will be needed to accomplish the project?
Financials. What is the preliminary budget? What is the estimated total impact of the project (costs and benefits)? The project manager should provide cost estimates for the expected lifetime of the project, not just the time of delivery.
Estimated schedule. The schedule will be rough at this stage. Try to make it realistic. Base it on previous project experiences, if possible.
Known risks. Include some proposed ways of dealing with these risks.
Organizations may have standard formats in which this information is expected to be presented or methods that are used to estimate the financial impact. If you can look at a previously successful business case that may help format your business case the way that management likes to see it.
As its name suggests, the project charter is the document that kicks off a project. This document is a formal recognition of the project and its authority to call on the organization’s resources to execute the project. The charter provides managerial direction for the objectives and management of the project.
Project charters should include the following:
Project name and authorization date.
Project manager’s name and contact information.
Schedule overview, based on the initial draft schedule.
A high-level description of the project objectives.
Summary of the approach planned for managing the project.
List of roles and responsibilities.
Project charters may also contain additional comments or clarifications by stakeholders.
The charter is the founding document for the project. It is likely to be referenced repeatedly by those trying to affect the course of the project.
The level of detail in the charter is important. You don’t want it to have too little detail, or different stakeholders will read their own preferences into the charter and insist on their own interpretation.
Too much detail ties your hands and prevents you from doing what you need to do to bring the project in. The appropriate level of detail is going to depend on the project and the nature of the relationships between the different stakeholder groups.
It is common for two scope statements to be produced during the early part of a project. Frequently, a preliminary scope statement (a “vision statement” or “scope charter”) will be created from the project charter and circulated for discussion.
A more detailed scope statement would be generated later to direct the project and to act as a control on scope creep.
The initial project charter is a very good place to start when developing the initial scope statement. The scope charter is likely to be high level and is likely not to specify technical means required to achieve results.
There will be several scope statements circulated during the initial stages of the project. Each will become more detailed and will reflect the emerging consensus about what this project consists of.
There will always be pressure to expand the scope of a project. If the scope is allowed to grow too large, the project will lose focus and may never reach completion.
There is a lot to be said for creating one project to create the base functionality and foundation for further growth. Additional features can be added as additional projects.
Reducing the scope in this way increases the likelihood of success, and also cuts the time required to deliver meaningful functionality to the business.
When trying to decide what should be defined as base functionality, a good test is to look at the business impact of the different proposals. The key is to get significant business impact delivered quickly, in a way that will enable further enhancements to also be delivered efficiently.
Here is a common way to structure a scope statement. Depending on the complexity of the project, the “Requirements,” “Product Deliverables,” and “Success Criteria” sections may be split out into separate detailed documents. In that case, include a summary in the scope statement and a pointer to each detailed document.
Project Title: This is a unique name for the project. It is used to track project progress and costs in reports to management.
Document Version Number: This document will evolve over time. To see which version is current, a version number should be assigned to each version and incremented as the document is updated.
Date: The date the document was prepared by the project management team.
Prepared By: The name and contact information (including phone number and email address) for the project managers who prepared the document.
Project Justification: A brief one-paragraph description of why the project is necessary, including:
Who requested the project
A very brief description of what the project will accomplish.
The roughly estimated budget
Requirements: A numbered list of the requirements for the project. The initial list of requirements will probably be very general. The requirement specifications will become more detailed over the course of the project.
Requirement numbers should not be re-assigned if requirements are retired; a requirement should keep the same reference number throughout the course of the project. If a requirement is removed, line it out rather than re-assigning its reference number.
Deliverables: This will be a list of what the project manager is committing to deliver as part of the project.
Project Management Deliverables:
The list of the project-management related material that the project manager will deliver throughout the project.
Some common project management deliverables include: business case, charter, team contract (an agreement by each team to deliver required resources), scope statement, WBS (work breakdown structure, a structured task list), schedule, cost baseline, status reports, project presentation, project report, lessons-learned reports, and project budget.
These are the deliverables that will specifically address the requirements. Deliverables should directly reference (by requirement number) which particular requirement they are fulfilling. As the scope document becomes more detailed, these deliverables will include specifications on what constitutes a successful delivery.
Project completion within budget and on the schedule are typical examples of success criteria. Special points of emphasis should be included here, such as specific milestones or deadlines that have a significant business impact.
When stakeholders agree to postpone a feature for a later version, keep track of the agreement. Otherwise, you will find yourself having the same discussion over and over, reminding people that the feature was postponed.
If you don’t manage the scope, it will manage you. Every stakeholder has a distinct view of what the scope of the project should be. Once you have a preliminary scope statement in place, changes can only be permitted within the context of project change control.
The tools you have at your disposal to manage the scope are
This starts with deciding how the preliminary scope statement will be developed and evolve. Throughout the lifetime of the project, this planning process will have to be robust to define an achievable scope and filter proposed changes.
As the scope develops, the task list or work breakdown structure (WBS) has to develop at the same time. If scope changes are not reflected and tracked in the WBS, project management will not focus on the correct issues.
Verification and control.
The scope change management process has to be robust, and project management has to be disciplined about enforcing its use. Stakeholders must agree to the downstream effects of project plan changes, including resource and schedule impacts of changes.
Each of these tools must be in place to manage a project’s scope properly. An accurate WBS is impossible without a solid scope statement, and a stable scope statement only exists if the planning and control processes are also solid.
Note As part of the scope verification process, the completed project scope statement must be accepted by the stakeholders. Stakeholders need to agree to a clear change control process, including a strong change control board (CCB).
If you don’t instill this discipline up front, you will spend a lot of time regretting it once you get into the meat of the project.
You have a few tools at your disposal to manage the scope, but political pressure will always be brought to bear to implement changes to the scope. There are a few different techniques you can use to combat scope creep. These would be used in conjunction with your change control process:
Cost. Put a dollar amount on the resources required to implement a change, and ask the requestor and CCB to identify the budget the costs should be charged to. Once it comes down to budgetary dollars, people start getting serious about which scope changes are actually necessary.
Time. Put time on the delay that the request will cause to the project timeline. When people have to take responsibility for delaying the overall project deliverables, people become more flexible about the changes they are demanding.
Trade-offs. Ask which existing requirement should be dropped to free up the resources needed to execute the change. There are always limited resources, and the most important items should be done first. By pitting requirements against each other, you force a decision about which priorities should be addressed first.
Early in the project, a project manager needs to identify the stakeholders and decision makers. For each of the stakeholder groups, escalation procedures must be identified to deal with the unexpected.
Stakeholder management can be like herding cats. Different teams have different priorities. One of the more difficult tasks a project manager has is to identify a reasonable path forward that addresses all the most important stakeholder concerns without blowing either the budget or the timeline.
For anything beyond a simple project, project managers should produce a separate analysis of the stakeholders in the project. This should include information about the organization and contact information for different stakeholder communities. It also may contain information about concerns about different stakeholder communities.
This analysis probably should not be part of the public project management plan because some of the information may be confidential.
The stakeholder analysis may only be shared among people directly responsible for managing the project so that the project managers can feel comfortable communicating personal information about the stakeholders, and how to adjust the project management methods to fit their needs.
[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]
Stakeholders will need to agree to team contracts. Depending on what is required from the stakeholder, the contract may include the following items:
Agreement with the initial scope statement.
A procedure by which changes are made to the project scope, requirements, or deliverables.
Commitment to provide the resources specified in the project plan.
One of the key coordination tasks for a project manager is the definition of a task list (sometimes called a work breakdown structure or WBS). The task list needs to identify a brief description of the task, the person (or group) responsible for the task, the approximate amount of time required to execute it, and the dependency relationships between tasks.
Specifications and requirements are not included in a WBS. A WBS only includes tasks; specifications and requirements are tracked separately. Because the requirements may affect the time estimates for a task, it is important to have the implementers review both the requirements and the time estimates.
The WBS is created by breaking down the project deliverables into smaller and smaller chunks. Each of these should continue to be decomposed until they arrive at the level of a task that is assignable and schedulable.
These tasks at the lowest level of a WBS are sometimes called work packages. The amount of effort represented by a work package will depend on the length of the project and how frequently updates are required.
Resource and dependency schedule will usually be handled at the work package level, so that is the level where the project manager needs to provide tracking and accountability. If weekly updates are needed to keep a multi-month project on track, for example, a work package should include no more than 40 hours of effort.
There are a number of tools that can be used to track task lists and dependency relationships.
Microsoft Project is the best known of the commercial tools. There are also free tools such as GanttProject (http://www.ganttproject. biz/download) that have similar functionality, and can even save files in MS Project format.
Some project managers prefer old-fashioned spreadsheets, but those can become unwieldy once the project grows past a certain size.
Whichever tool is used, the most important basic analysis is done at the task level. If you don’t know what you want people to do, there is no way you are going to be able to estimate the resources you need to do it.
As you define the list of tasks, you will need to speak to the teams who will execute those tasks for estimates of the time they will need, the number of people they will need to commit, and the dependency relationships they have with other tasks.
It is very common for one task to need to be split up into smaller tasks assigned to different groups.
A rule of thumb is that any project can be decomposed into 10–20 items. Each of these can be decomposed further until we get to a level where each item is a work package. This is an example of a “top-down” method for producing a work breakdown structure.
There are a few different approaches that project managers use to develop a WBS. Some of these include:
Analogy. If you have a WBS for a similar project, that is a good starting place. The estimated and reported task durations also may be useful in coming up with schedules for the current project.
Top-down. Starting with the high-level tasks, break these down into component pieces. This approach is best used by someone with a deep understanding of what needs to happen in the project, perhaps someone with a good implementation background.
Bottom-up. Identify as many detailed pieces as possible, and collect these into groupings of high-level tasks. This approach can help develop buy-in from the implementation teams, and it is effective for some projects that represent a new way of doing things.
Mind mapping. This is a technique that starts with an objective drawn in the center of a diagram, perhaps on a whiteboard. Tasks needed to accomplish that objective are drawn as branches from the center, and subtasks are branches from those tasks.
This is a good technique for brainstorming during early project meetings to try to capture the different requirements.
Of necessity, several of the tasks will have descriptions that are telegraphic, if not vague. A WBS dictionary should be included to define what each task means. This is usually a document that is distributed with or linked to the WBS. The WBS dictionary may include links to the requirements.
Here are a few principles to follow when constructing a WBS:
Uniqueness. Each work package appears only one place in a WBS.
Dependencies can be defined in the tool used to create the WBS. (This is much easier in a specialized tool such as Microsoft Project or GanttProject, as opposed to a spreadsheet.)
Nesting. Each WBS item consists exactly of the work packages below it in the WBS hierarchy. Dependencies should be tracked as dependencies, not by considering a work package to belong to two different hierarchies.
Accountability. Each WBS item belongs to a named person, even if some of the work packages are done by other people.
Consistency. The WBS needs to be consistent with how the work will actually be performed. The structure must be defined by reality, not aesthetics.
Buy-in. The project team has to be involved in constructing the WBS, to develop buy-in and ensure consistency.
Clarity. WBS items must be understandable, which probably means a definition in the WBS dictionary.
Flexibility. The WBS must be constructed in such a way that updates are doable. No matter how much planning and discussion is done up front, there will be changes. It is easier to implement these changes in a project management tool as opposed to a spreadsheet.
Throughout the project, the project manager is responsible for tracking the resources needed to bring the project to completion. This includes the people needed as well as the cost in dollars, facilities, and material.
A preliminary estimate is drawn up before the project is approved, but the project manager has to keep a handle on the resource estimates as they change over the course of the project.
The basic tool for making the resource estimates will be the task list. Most projects have a large number of similar tasks; as each task is completed, you need to see if timelines for other tasks will need to be adjusted.
The advantage of a project management tool (rather than a simple spreadsheet or document), is that it will automatically adjust timelines and estimates based on changes to tasks in the plan. It will also help us view critical path changes.
The critical path is the name given to the path of tasks that is keeping the overall project from being any shorter.
Each task can be viewed as being part of a tree of dependency relationships, both of tasks that must be completed before this one, and also the tasks that are waiting for this one.
The critical path is calculated by looking at the duration of tasks in a dependency tree and selecting the dependency tree with the longest time duration.
This particular path is the “critical” path because if some of its elements can be shortened, the overall project timeline can be shortened. Or, if one of its tasks is delayed, that will cause a delay in the overall project.
One of the earliest indicators of a project in trouble is when the resource requirements start to spiral up. It is the project manager’s responsibility to track these requirements against what was approved for the project and to alert project stakeholders if they start increasing in a way that puts the project in jeopardy.
As the WBS is completed, there will almost certainly be people who are assigned more tasks than they can possibly complete in the times assigned. When this happens, the project manager has a few tools that can be used:
Identify tasks or parts of tasks that can be done ahead of time.
Reschedule some tasks to different parts of the project plan, so that the person can focus on the more critical tasks first.
Find ways to re-assign some of the work to other people, perhaps by bringing in temporary help.
It is a myth that more people mean a faster project completion. There is overhead associated with managing new people and bringing them up to speed. Even when they are up to speed, there is additional communications overhead for each additional person.
Brooks’ Law Adding more people to a late project makes it later.
Brooks’ Corollary There is an incremental person who, when added to a project, slows down the project delivery.
Estimation is not an easy skill to learn. When you find that your estimates are significantly off, you will need to find out what you are missing. Many technical people dramatically underestimate the amount of time required for planning tasks such as sketching designs or attending planning meetings.
Try to identify the types of things that are being missed in the estimates by asking clarifying questions. Once you identify someone’s blind spots, help them to account for them in their estimates. It may be as mechanical as giving them a template including lines for the frequently overlooked items.
For each task in the WBS, you need three numbers. You will need a best case, worst case, and most likely you will need to estimate for the amount of time needed for the task. These numbers will be used to perform scheduling estimates. PERT analyses are a common way to provide schedule estimates.
Allow time for things to go wrong in the overall project schedule. Projects of any complexity will have something go wrong that will take more time.
Programming in enough slack time without allowing the team to procrastinate and lose focus is an art, not a science. One way to do this is to add explicit WBS tasks under project management control for resolving variances.
Project teams tend to underestimate how long it will take to do something. This isn’t because we are lazy or dishonest.
People who gravitate toward project work have a certain mindset. We like to accomplish something new. (Even better to accomplish something that everyone else thinks is impossible!)
If we spent all our time thinking about what could go wrong, we would never finish the project, and we would probably never be invited to be a member of another project team.
When you are working on a schedule, question your assumptions. Are you assuming a best-case scenario? What unknowns could come back to clobber us? Make sure your schedule takes realistic estimates and risk assessments into account.
An overly precise schedule is an early indicator of problems in the project planning process.
Precision is very easy to achieve. Accuracy is much harder. You can spend a lot of time tweaking a schedule beforehand, but any non-trivial project schedule will need to be adjusted anyway as difficulties come to light.
Here are a few suggestions for improving the quality of your schedule estimates:
How accurate should the task estimates be? Are you looking for a guess? A good estimate? A thorough analysis? You will want to focus more attention on tasks that are on the critical path or that are part of a lot of dependency chains.
When you request an estimate from an implementation team member, you can ask for accuracy in terms of a confidence level. (Are you 50% sure? 80%? 90%?)
Treat these numbers as a way to communicate expectations to team members, but take those numbers with a grain of salt. (Don’t just use them for scheduling estimates because research shows that people routinely overestimate confidence levels.)
Don’t ask for precise estimates of less important tasks. If you chew up all your team’s time making really good estimates, you will have less time to actually execute the project.
Trust the experts. You can probably pressure the programmer to give you a smaller time estimate, but that doesn’t mean that the work will actually take less time.
Provide accurate requirements. You can analyze garbage to within an inch of its life, but you will still get garbage output. Use previous project work as a baseline wherever possible. Just understand where the information is comparable, and where it is not.
The project scope is a general statement about the size of the project. Beyond that, stakeholders must agree to specific requirements and success criteria.
A requirement is a problem statement. It does not attempt to specify how the problem will be solved; it states the problem in a clear enough way that a knowledgeable person will be able to work toward a problem resolution. A good requirement statement is easy to understand, but hard to misinterpret.
Note Requirement statements are a form of communication. If they are not understood by both the requestor and the implementer, they need to be revisited.
Frequently, stakeholders will try to use these requirements to expand the scope of the project. The project manager must keep a handle on scope creep. If the scope needs to be expanded, stakeholders and decision-makers have to allocate the resources to do so or reduce requirements elsewhere to free up the necessary resources.
Note Part of tracking requirements will be tracking the differences between the requirement statements and what actually comes out of the project. These differences are known as variances.
Variances need to pass through change control approval to be acceptable. Regardless, variances must be tracked and resolved as part of successful project completion.
Software engineering makes a distinction between C-requirements (customer requirements) and D-requirements (developer requirements). C-requirements are usually high-level descriptions of behaviors that are wanted or needed; D-requirements are the specific, detailed requirements that developers use to implement the C-requirements.
There needs to be a clear mapping between C-requirements and D-requirements. Standards that are based on the IEEE 930-1993 and 830-99 standards for expressing requirements use a unique identifying number for each requirement. For projects that have more than a trivial number of requirements.
I recommend that you assign each requirement a number, that each D-requirement specifies a corresponding C-requirement, and implementation work packages reference a D-requirement. Otherwise, you will spend way too much time answering questions about why things are being done this way.
If your organization has a standard way of expressing requirements, use it. If not, you can do a lot worse than downloading the 930-1993 and 830-99 standards from IEEE and using them as a template for assigning requirement numbers.
Requirements should be expressed in a standard way:
Assign a unique identifying number to each requirement, preferably as part of a numbering structure that makes sense.
Each requirement needs a brief descriptive name.
The requirements should be published and easily findable. This means that the specifications document should be in a well-known location, and it should be structured so that specific types of requirements are easy to find.
Requirements should be accompanied by tests to verify them. (Some methodologies define the requirements based on the tests required to verify them.)
Requirements should point at the code sections or work packages that implement them, and vice versa.
Testing results should be indexed by the required number. That way, we can identify tests to validate each requirement, including unit, integration, and system-level tests.
List ASSUMPTIONS EXPLICITLY
Which project goals have not been made explicit in the documentation?
Which disagreements between team members may delay the project?
What are the underlying architecture and technology infrastructure?
Which standards or other organization requirements must be met?
Are there regulatory requirements that must be fulfilled?
Which expected organizational changes might impact the project estimates or team structure?
Are the definitions clear?
Have all the different teams been represented in the planning discussions?
Requirements can come out of interviews or workshop sessions. Sometimes requirements can be gathered by directly observing business processes. Gathering requirements is a skill that is developed over time.
Professionals who gather business requirements for implementation are frequently known as business systems analysts.
There are several techniques that can be used to identify and nail down requirements:
A mock-up is a nonworking model of a project component, usually used to demonstrate user interface functionality.
A prototype is a working model of a component of the overall system. This method is especially useful for getting buy-in to interface requirements because the input can be restricted or output canned to reflect look-and-feel types of operation.
As components become more developed, they can be placed in a test harness to see how they would integrate into the whole.
Use-case modeling is a technique for identifying the steps that would happen as a system handles a typical operational case. This is less mechanistic than the way that a lot of techies look at how the system should operate, but use cases are accessible to most stakeholders, and they still provide a useful level of detail to the technical staff.
Joint application design (JAD)
This is a method that involves intense, structured workshops including all the stakeholders to try to bring out all the requirements.
JAD brings the user community representatives into the requirements process in a focused way, which helps to increase their involvement and buy-in.
Beyond gathering requirements, you also need to get a feeling for how important each requirement is. Are they based on wants or needs? As the project progresses, there will be times you need to adjust the scope of the project, and it is best to know which parts of the scope have some flexibility in them.
Use cases, in particular, are a really useful way to gather C-level requirements at a useful level of detail. The information in a use case should include:
Use case ID: Unique identifying number, preferably mapping to a C-level requirement.
Summary: Verbal description of the use case.
Rationale: Why the use case is needed.
Actors: Groups of people or external systems that interact with this use case.
Initial state: What needs to be in place at the beginning of the use case.
Actions: The course of events in the use case.
Alternate paths: Conditions where a similar, but not identical, the course of actions would take place. (This allows us to collapse several similar, related use cases into one.)
Final state: The status at the end of the use case.
INTERVIEWS TO GATHER REQUIREMENTS
The first step to gathering requirements is to identify who to interview. Generally speaking, the people closest to the business process in question are good people to answer questions about how the business process works.
Another good group of people to interview are the people who manage the application as it currently exists. They probably have a good view of what works and what does not in the current system.
Here are some questions that need to be answered to pull together requirements:
What benefits do we expect from this project?
What problems are we trying to solve?
Who will manage the system when it is complete?
Who are the direct users of the new system?
Who are the indirect customers for the new system?
Who does this system need to talk to? (Where does it get input from? Where does output go?)
What format constraints do we have on input and output?
What performance or Service Level Agreement (SLA) constraints exist for the system?
What sort of pain points exists with the current system?
Are there pain points adjacent to the existing system that can be eased by designing this system a little differently?
Are there training materials for the existing system that we can examine for requirements?
What do typical requests look like for the existing system? How are they currently processed?
Requirements should be identified with a unique requirement number. Especially if there are more than a few requirements, it makes cross-referencing much easier when setting expectations for work packages or user acceptance testing.
It probably makes the most sense to structure requirements in a nested structure, with high-level requirements being broken down into lower-level requirements.
Obtain a database server
The server must be compatible with organization standards
The server must have at least 4 cores
The server must have at least 4 GB RAM
These numbers need to remain consistent throughout the project; you will drive yourself insane if you keep trying to update all the places a requirement number appears in the project documentation every time a requirement is removed or added.
If a requirement is canceled, the requirement document should be updated to reflect its cancellation, but the number should not be re-assigned.
In addition to describing the functioning of the system (functional requirements), there are a number of nonfunctional requirements that need to be considered. It may be necessary to negotiate some of these.
Reaching certain thresholds, for example, may require a larger investment than the customer wanted. In that case, options can be presented as part of the scope conversation.
COMMON NONFUNCTIONAL REQUIREMENTS
Availability. Uptime and network availability requirements for different parts of the system.
Scalability. How quickly and easily additional resources can be brought online.
Portability. How easily the system can be moved. This may include moving it to a different platform or vendor.
Security. What type of security requirements are in place for the system or network communications.
Fault tolerance. How well the system deals with component failures.
Performance. How responsive the system is, and how much throughput capacity it has.
Usability. How user-friendly the system is.
Flexibility. How easy it is to bring additional features or components online.
Data integrity. The level of checking to ensure that data remains consistent and correct.
Part of dealing with requirements is validating that they have been achieved in the final project result. If you specify what the requirements mean when you define them, it makes it much easier for the project team to hit them.
You will need to have representatives of the user community available to answer questions and to directly verify that the requirements have been met in user acceptance testing. The earlier components can be tested, the more time there will be to take care of any variances that appear.
Project Management Plan
The project management plan for each project will be unique. It needs to be complete, but should only include what is needed to complete the project successfully. This is a balance because a simple project will need a lot less detail and structure than a complex multi-team project.
Structure for a Project Management Plan
Depending on the environment where you find yourself, you may have a project management plan template that you are expected to use. Some common standards include templates that are included with Microsoft Project, as well as US Department of Defense standard 2167 and IEEE 1058-1998.
Here are some common sections and ideas that should be included in a project management plan:
Project name. This should be a unique project name that can be used to help management track the progress of this project.
Project description. A brief description of the project in a common language. It should include information on what the project is for, how much it will cost, and how long it will take.
Project sponsor. The name and contact information for the sponsor of the project.
Project management team. The names, positions, and contact information for the project managers and key stakeholder representatives. This should include a brief label indicating the role of each representative in the project.
Deliverables. This section will be similar to what is in the project scope and should include pointers to more detailed documents as needed.
References. Links to key reference or historical documents should be included. This may include references to organization processes, procedures, or policies that are relevant to the project.
Definitions. Because this will be viewed by nontechnical people, the plan should have as little jargon as possible. Where jargon or technical terms are needed, they should be defined for nontechnical readers.
Organizational information. This may include something like organizational charts for the people working on the project, as well as a description of the roles of the different people involved in the project.
Management objectives. Management’s view of the project’s priorities and constraints.
Controls. Description of how the project progress will be tracked, how changes will be authorized, and any gates or milestone approvals that will be used during the project’s lifetime.
Risk management. How the project team will identify, report, and track risks and issues identified during the project.
Staffing. Which type of experts are needed to execute the project, and from which groups?
Tools and processes. What tools will be used to document and track the project and its deliverables? How will the information be recorded using these tools?
Work breakdown structure (WBS)
Deliverables. Similar to what is in the scope document, including information about quality expectations.
Schedule. For anything beyond the trivial, both a summary and a detailed schedule should be provided. If the WBS is built properly, that can help build the schedule.
Budget. Both a summary and a detailed budget should be specified.
The project manager should get agreement to a risk management plan as part of the initial project plan approval. This includes maintaining a register of risks and issues associated with the project.
Some elements to include in a risk management plan are the following:
Contingency plans for risks that are foreseen early in the project.
Fallback plans for risks that may have an especially significant impact on project delivery.
Contingency reserves of time, money, resources, or approvals that can be accessed by the project management team to deal with risks.
Note One way to rank risks is to express the likelihood as a percentage, and the impact in dollars. (This may mean translating project delays or man-hours into a rough dollar figure.) Multiply those numbers for each risk, and compare the results to rank which risks need the most urgent attention.
For example, if risk A has a 50% likelihood of costing $10,000, and risk B has a 10% likelihood of costing $20,000, then risk A has an expected cost of $5,000 (.50 × $10,000), and risk B has an expected cost of $2,000 (.10 × $20,000). Risk A would be considered the more urgent risk, in this case.
Risks can be dealt with in one of the following ways:
Avoidance. The threat is entirely avoided, probably by eliminating the causes.
Mitigation. This means that the risk is reduced to acceptable levels by taking an action or setting up a contingency plan.
Transference. The negative effects of the risk are assumed by another party. Insurance is a good example of risk transference.
Acceptance. The risk’s downside and likelihood can be examined to see if the organization is willing to accept the risk. Usually, this will only be the case if mitigation actions have been taken to reduce the risk to acceptable levels.
Risks need to be tracked by the project management team. A risk register should be published and made available to the stakeholder community.
Project team members should report all known risks to the register to be analyzed, and the project management team should set up interviews and brainstorming sessions early in the planning process to try to identify known risks.
ELEMENTS OF ENTRIES IN THE RISKS AND ISSUES REGISTER
Unique identifier. If a unique number is assigned to each risk, it makes it easier to cross-reference the risk in other project documents.
Seriousness. The seriousness of the risk should be ranked, perhaps with a numerical scale indicating how serious the risk has been evaluated to be, based on its likelihood and potential impact.
Name. The risk should be given a unique short descriptive name for discussion.
Description. The risk should be described, or a document containing a full description can be referenced.
Category. This will indicate which part of the project team needs to deal with the risk or its impact.
Triggers. Symptoms that indicate that the risk may be active.
Responses. Mitigation actions, contingency plans, or other possible responses to the risk.
Owner. The person assigned to deal with the risk.
Likelihood. How likely is the risk to occur? This could be in percentages, or in terms of high/medium/low.
Impact. What is the downside risk?
Status. Has the risk been mitigated or accepted?
As the project progresses, the project manager is responsible for looking at how the dependency relationships are affecting the overall project timeline. In particular, the project manager needs to keep a close eye on the sequence of tasks that make up the critical path.
A dependency is a relationship between tasks that have an impact on how they are sequenced or scheduled.
Mandatory. Some dependencies are inherent in the nature of the tasks. These are known as mandatory dependencies. You can’t install a database until the server is powered up, for example.
Discretionary. These are driven by the project management team or by the practices and procedures in place in the environment. For example, you don’t want to start coding until the requirements are defined.
External. Some dependencies are driven by items external to the project. These should be tracked on the WBS, along with expected delivery dates.
There are a few different ways that dependency relationships can have an impact on task scheduling. It is important to track the type of dependency, as these can have very different effects on schedule.
Finish starting. The first task must complete before the second task can begin.
Start to start. The second task cannot start until the first task does.
Finish finishing. The second task cannot finish until the first task does.
Start to finish. The second task cannot finish until the first task starts.
There are several ways to diagram dependencies. Project management software, such as Microsoft Project and GanttProject, will take care of these diagrams for you, as long as you put the dependency information into the project plan.
In general, dependency relationships are represented on a network diagram, where the first task is at the tail of an arrow, and the second task is at the point. Depending on the type of network diagram and type of dependency, the arrow location and shape may be different.
The points of interaction between the groups and elements of the project are a particular type of dependency that needs special attention.
When these interfaces are points of contact between the two groups, you are responsible for making sure that they are working together smoothly and communicating the information needed so that their respective contributions come together correctly.
The number of interfaces grows very quickly as the number of elements increases. A good project manager is able to identify the critical interfaces early and monitor them throughout the project cycle. When these interfaces break down, that will affect multiple elements of the project plan.
There are certain places in the project plan that are natural places for making sure that the project is remaining on track. These milestones need to be tracked to make sure that the overall project is remaining on the schedule.
They also should be reported to the stakeholder community to build confidence in the project and a sense of momentum that will help carry the project through to completion.
Milestones need to be specific, measurable, assignable, realistic, and time frame. (Project managers refer to these as SMART milestones.) Beyond that, they need to be well-chosen, to reflect the progress of major phases of the overall project.
Staying on Track
The time estimates in the WBS are an important tool for tracking whether you are on target to hit a milestone. Items on the critical path are the ones that need the most focus, but the critical path may shift as people report different work packages completed or delayed. Make sure to get status on each work package, including time estimates.
Publish the time estimates provided by the project team. If the estimates are not written down and tracked, they will slide. When things are delayed, as they will be, work with the accountable people to find out why and try to identify a way to get the project plan back on track.
Milestones are also appropriate times to review project progress. In the event that the cost and/or schedule are increasing rapidly, these reviews are the time to either adjust the scope, commit the additional resources, or maybe even scrap the project.
These reviews are sometimes referred to as “kill points.” The worst thing to happen to a project is to have its costs spiral out of control, and never to produce anything. If the project starts to go down that path, it may be best to kill it and go back to the “concept” phase to replan.
Each project phase should be considered to be a milestone. At each phase of the project, the project manager is responsible for checking with stakeholders for an agreement that the project is meeting the project requirements.
Identify and Schedule Resources
As different resources will be needed during the project execution, the project manager is responsible for lining them up. This includes people as well as facilities, equipment, or vendor participation.
One of the most important duties of a project manager is to look around the corner to see the next approaching pain point and to arrange to alleviate it before anybody else realizes it is coming.
Stay in touch with the people who are executing the work, and provide opportunities for them to approach you with problems. These problems can have downstream effects on resource requirements and scheduling for other parts of the project.
Scope Change Control
Scope and requirement changes are sometimes necessary, but they are costly in both money and time. Changes should not be undertaken lightly.
The project manager is responsible for making sure that any changes to scope or requirements have complete buy-in, including explicit commitments of the resources needed to implement the changes.
Part of a project manager’s job is tracking these changes and considering their impact on other parts of the project. The project as a whole may be delayed as a result of a change to a particular component or task.
During the project, the project manager will need to identify, evaluate, and manage the changes that are proposed during the project.
Team members need to understand that changes need to go through the approval process; otherwise time will be wasted with intergroup conflict, and it may be necessary to destroy something that was close to completion if it includes unauthorized changes.
Changes can be the most contentious part of a project. Project managers need to be well-organized and retain documentation about changes that are considered, rejected, accepted and implemented. Documents to be tracked include:
Change requests, and whether they are approved or rejected.
Reported defects, either in the plan or in the product.
Remediation actions are taken to resolve these defects.
Preventative actions are taken to avoid issues.
Approved updates to the project scope and plan
It is unwieldy to get approval from every stakeholder for every change. Most changes would be reviewed and approved by a change control board (CCB) made up of representatives of the key stakeholder groups.
It usually makes sense to have regularly scheduled CCB meetings so that team members know when changes need to be submitted, and when an answer can be expected. In a time-sensitive project, CCB review meetings should be scheduled frequently.
The CCB needs to include enough representation from the key communities to ensure that risk assessments and necessary communications have been carried out properly.
The project management team, user community representatives, stakeholder representatives, engineering and development resources, and other specialty communities should be represented on the CCB.
Team members also will need guidance on the format that is expected for change requests.
Reporting Project Status
Execution is great, but the plug will be pulled on the project unless the project sponsor and the key stakeholders are able to see concrete progress.
It is the project manager’s responsibility to provide accurate reports of the project status. You will want to develop standard templates or a dashboard for reporting project status. The goal is to allow stakeholders to identify project status at a glance, preferably without interrupting you for a personalized update.
When a Project Is in Trouble
Killing a project is a huge decision, especially if a project has been allowed to meander out of control for some time. Being the project manager for a large failed project is a career limiting move. If you keep tight control from the outset, you are much less likely to have to kill a project further along.
The crisis moment when people decide to kill a project is almost never the first sign of trouble. Trouble should have appeared earlier when someone realized that the dependency relationships were wrong, or the amount of time for a task was totally wrong, or that something happened that was going to blow out the budget.
When things go wrong, they will not fix themselves. Jump in right away to get the project back on a firm footing.
Convene a meeting of the technical experts to find out what the situation is. Make sure everyone understands the difficulty. Collect ideas on how the difficulty can be worked around.
Collect all the information, but get it quickly. You do not have time for analysis paralysis.
Present the difficulty and any needed changes to the project sponsor. Changes will need to be approved by the stakeholders.
Reward people who bring problems into the light.
“Shoot the messenger” reactions just mean that you won’t find out about the next problem in time to do anything about it.
After the difficulty is resolved, convene a “lessons learned” session to identify what went wrong in the planning process. Might the same thing have happened in another part of the project plan? If so, fix it now.
Most people are reluctant to come forward and say that a project is in trouble. One way of identifying projects that are in trouble is known as earned value management (EVM).
Earned Value Management
EVM is a method for tracking the costs of a project and making sure that the money spent on the project is being matched by progress on the project. EVM involves calculating the following:
Planned value (PV). This is the amount of money budgeted to be spent during a project period. “PV to date” refers to the total planned value expected to have been spent on the project to this point in time.
Actual cost (AC). This is the amount actually spent during that time.
Budgeted actual cost (BAC). This is the amount that is budgeted for the entire project.
Earned value (EV). This is an estimate of the value of the work completed during the time period.
The rate of performance (RP). This is the fraction of planned work that was to have been completed by the end of the time period. (This can be calculated based on the percentage completion numbers from the WBS.)
Cost variance (CV). This is a comparison of the amount expected to have been spent during a time period against the amount actually spent. It reflects whether the work costs more or less than expected, based on whether the CV is negative or positive, respectively.
Schedule variance (SV). Similar to CV, this reflects the amount of work completed against the amount of work expected to have been completed.
Cost performance index (CPI). This is a measure of how well the project is staying within its cost estimates.
Schedule performance index (SPI). This is a measure of how well the project is staying within its schedule estimates.
Estimated actual cost (EAC). This is the estimate of what will actually be spent, assuming that the CPI remains constant through the rest of the project.
Estimated time to complete (ETC). This is an estimate of the amount of time that will be needed for the overall project, assuming that the SPI remains constant through the rest of the project.
EXAMPLE: EXAMPLE EVM CALCULATION
Assume that the amount expected to have been spent to date is $10,000, that the actual amount spent was $15,000, and that the percentage of planned work completed so far is 50%.
If someone told you that the project was going slower than expected and still running over its budget, you would know that the project was in trouble. EVM gives you a quantitative tool to estimate just how bad the damage is, and to compare projects that are in trouble.
To deliver a quality product at the end of the project, you have to track the quality of the deliverables throughout. This will involve having a test plan in place that will validate the different deliverables as they are reported complete.
Beyond checking the quality of the deliverables, you also have to check that the interfaces between different components work properly.
Most important of all, you have to verify that the project meets the requirements of the user community. This is best checked as thoroughly as possible while the project is running, rather than delivering a complete package at the end for verification.
To the extent that prototyping and test harnesses can be used to allow users to check components, you will be able to avoid unpleasant surprises at project delivery time.
A high-quality project deliverable will both conform to the requirements for that deliverable, and will also be fit for use in the manner intended. If both things are not true, the quality of the deliverable is not acceptable.
To have high quality, you need your planning process to support good requirements gathering, your quality assurance process needs to guarantee that deliverables are of acceptable quality, and your quality control process needs to identify and implement ways to improve quality.
Quality is usually measured by testing. If the detailed requirements are complete, the test plan can follow what is specified for each requirement. Each requirement should include one or more acceptance tests for determining whether the requirement was met.
Some important criteria for acceptance tests are:
Functionality. Does the component meet its functional requirements?
Outputs. Are the outputs from the component produced in the required format? This is important whether the output is intended for a user interface or a program interface.
Performance. Is the performance and system resource utilization of the component adequate for real-world operation?
Reliability. How maintainable and reliable is the component?
Testing needs to be performed at several different levels as project components are delivered. These can be combined to the extent practicable, in order not to leave rework or major problems to be discovered at the last possible moment.
Code review. Any code should go through a review process. It needs to comply with naming, structure, and documentation standards for the organization.
Unit test. Each component is tested by itself, perhaps in a test harness, to ensure that it fulfills its requirements.
Integration test. Each component is tested in combination with the components that share an interface with it.
System test. The complete system is tested by the implementation team.
User acceptance test. The complete system is tested by representatives of the user community.
The earlier in the process an error is caught, the less expensive it will be to fix it. The amount of time saved by an appropriate review and testing schedule will more than pay for itself over the course of the project.
Reviews are critical. It is impossible to simply “test in” good quality. Good quality starts with good requirements and a good design, then continues through the rest of the build process. Good quality is built in from the ground up.
When management decides to cut time from the project, testing is usually the first target. That is a false sense of savings; the time cut from the project plan is likely to be more than wasted in dealing with the problems that were not caught earlier in the process.
Sometimes problems emerge in testing that needs to be identified. the blog discusses tools that can be used in group troubleshooting and root cause analysis sessions.
When the project is delivered, the project manager’s job is not done yet. There are still a few more tasks that should be undertaken to wrap up the project.
User acceptance results. Document the user community’s sign-off that project requirements have been met.
Lessons learned. Obtain information from the project team about lessons that have been learned during the project’s execution.
Finalize project documentation. Finish filling out the WBS with delivery times, and archive project documentation for reference by the next project manager.
Final budget. Prepare the final project financial statements, including expected maintenance and other costs during the expected lifetime of the project’s deliverables.
Documenting Policies and Procedures
During your initial 90 days, one of the things you need to look at is how your team’s processes and procedures are documented.
To the extent that you can use standard, documented processes, costly errors will be avoided. Not only does that make the environment more stable, it improves the quality of life of your staff, especially your senior staff.
Your documentation should be easy to find, edit, and update. There are a number of possible ways of doing this, including file shares, wiki or blog pages, and SharePoint. If there is an organization-wide standard, it makes sense to support it.
Documentation should be produced for both internal team use and for people outside of the team.
The documentation for people outside of the team should focus on what services the team can provide, and how requests should be filed and formatted.
People should be instructed on how to open a ticket, and they should be told what type of information and approvals are required for what types of requests. (If budget approval is required, that should be included in the request as well.)
If people know what information they have to provide for your team to fulfill the request sooner, it will help both the requester and the person from your team who executes the request.
Your documentation repository should include some type of index to make it easier to find documents (and to avoid creating duplicates). It should also include links out to other teams’ documentation or to organizational standards that need to be followed.
It is possible to go crazy with documentation. The bottom line is the bottom line, and you will be judged by the functionality and reliability of the environment you are responsible for.
Documentation is a tool to help you make the environment more stable and more flexible. Start with the documentation tasks that will help you achieve these goals, and work to build a culture where documentation is part of every deployment and every change.
POLICIES, STANDARDS, PROCESSES, AND PROCEDURES
Policies are statements by management that provide requirements to guide people who implement technologies and processes.
Standards are organization-wide platforms and methods that support the policies.
Processes are business methods and practices that support the standards.
Procedures are step-by-step instructions on how to carry out a task in a way that supports the organization’s policies and standards.
Ideally, every task would have a specific, standard procedure that has been vetted and approved as complying with policy. That is the ideal, but it is a very tall order.
In the real world, your group probably has some well-defined procedures, some procedures that have only recently been drafted, some procedures that exist only as emails or comments in a script, and some procedures that are so out of date that they would break the environment if someone actually tried to carry them out.
Some of your early wins should come from identifying the biggest gaps in your documented procedures and filling those gaps. Focus your attention first on procedures that:
Are frequently executed
Have a similar procedure each time they are executed.
Are able to be executed by more junior team members.
Are related to security or audit concerns (e.g., access-related requests or patch installation procedures).
In particular, if it is a procedure that will be entered into change control requests or audit responses over and over, it is far better to have a standard document that can just be attached (or a link that can be provided).
You may need to work to get policies approved if you see a gap in the policy structure. At the technology team level, your focus will probably be on procedures and maybe standards. Policies and standards are discussed in greater detail in the final two sections of this blog.
Procedures as Controls
When management defines a policy, they expect that the organization will comply with it. The enforcement of these policies is only possible if we track and verify compliance and report breaches of the policy.
A control is a method or facility that is used to enforce a policy. Procedures that implement a policy are examples of controls. Compliance teams may call on technology teams to certify that the procedures are documented and that they are in active use.
Demonstrating compliance can be done by logging changes, along with the procedures used. If the procedure can be automated, it becomes even easier to demonstrate compliance, especially if the automated procedure includes a logging step.
Changes that are controlled by policy should be tracked and logged. If you have a working ticketing system, it is easier to require that the requests be filed as tickets in a standard format. Then the person fulfilling the request can update the ticket with the procedure used when the ticket is marked as resolved.
When new facilities are added, controls should be built into the system at implementation time. The initial requirements should include implementing the controls. Because new implementations should be tested anyway, the testing procedures may serve double duty as compliance controls.
While looking for procedures that are priorities for documentation, keep an eye out for simple tasks that are done frequently. To the extent possible, these should be automated and even made into self-service requests for the customer.
Another target for automation would be multistep procedures that are not done frequently enough for people to be able to remember all the steps. If these can be scripted and documented, it will make a big difference in the reliability of the environment.
You will never be given enough staff or enough time to carry out the full extent of your duties. The way to work around this is to identify time-consuming tasks or frequent tasks that can be automated.
It takes some extra effort to develop, review, test, and deploy automated processes, but the time saved can be rolled into the next automation project. If you pick the right targets, automation projects can be good sources of early wins when you take over an environment.
Uncontrolled change is the enemy of a reliable environment. There are several important components of a functional change management system:
A system for obtaining approvals from stakeholders for changes.
A system for tracking change requests through the review and approval process.
A process for reviewing change requests.
Each change needs to include a brief description of the change, a specific plan of how the change will be executed, a specific plan for backing out the change, and the success criteria that will be used to test the change.
Each change should pass through several phases on its way to implementation:
Assessment. The risks of implementing the change need to be considered. Part of the assessment is testing the change and the back-out plans beforehand.
Planning. A procedure needs to be created and reviewed for executing the change, testing it, and backing out if necessary.
Testing. The procedure should be tested. How it is tested will depend on the nature of the change. If the procedure is standard, additional testing may not be necessary. If like-for-like testing is impossible, the procedure needs to be reviewed by the relevant subject-matter experts.
Communication. The change needs to be communicated to all of the stakeholders, including the information about what the change is, what the expected impact is, why it is necessary, and when it will be executed. The time, format, and manner of these notifications should be standardized, so people know where and when to look for them.
Authorization. The appropriate customer or service owner needs to approve the change, based on the information from the procedure and the assessment.
Documentation. The change needs to be thoroughly documented in a standard manner and location. Each change record should include information on the requester, approver, system status before the change, the reason for the change, specifics of the change, status after the change.
Whether the change was successful, whether the back-out was successful (if the change failed), dates and times of the different elements, and contact information for the implementer.
Validation. The requester and/or end-user community needs to validate the system after the change and provide a certification that the change was successful.
Part of making the change control system work properly is that you need people in different roles to review and approve changes:
Change requester. This may be an internal customer, or it could be someone from the technical staff. The change requester specifies the requirements and scope of the change.
Change owner. This is the person who shepherds the change request through the change control process.
Change implementer. This is the person who is responsible for implementing the change.
An incident is something that occurs outside of the normal functioning of the environment. Some incidents may result in a production service being affected in a measurable way. Depending on the nature of the impact, it may be necessary to execute an emergency change.
Detection and recording. Ideally, the monitoring system should open a ticket directly into the correct queue.
Classification and initial response. Someone from the team owning that queue verifies whether there is a legitimate incident, and does a preliminary investigation into the scope and cause of the problem.
Investigation and diagnosis. The relevant technical teams perform a more thorough investigation to diagnose the problem and propose a resolution.
Resolution and recovery. The resolution is implemented and the service recovered.
Incident closure. The incident is closed, and the customer representative validates the service.
The incident response framework needs to consider some important elements of incident response: ownership, monitoring, tracking, and communication.
WHEN YOU WON'T HAVE TIME TO ASK PERMISSION
Sometimes there is not the time to get proper authorization for a change in advance. If there is an outage or another emergency, it may be necessary to change things on the fly to restore service. There are a few principles to keep in mind when you find yourself in this situation:
Don’t do anything that can’t be reversed.
Keep track of everything you do.
Follow the organization’s incident response process.
Report on the changes you introduced into the environment after the fact.
Those changes should be reviewed once the emergency is past. If the review board decides to keep them, they can stay as part of an emergency change. Otherwise, they can be reverted as part of a scheduled change.
Don’t hide the actions you take to resolve a problem. Report them honestly and help clean up and document the environment as needed. Incident response should be handled in a standard way to instruct and protect the operations and implementation teams. Here are some common elements that need to be defined:
The timeframe for the response as frequently defined in the Service Level Agreement (SLA) for the facility in question.
Notification requirements for the response and stakeholder teams.
How problem resolutions should be tracked, logged, and approved.
How logs and other evidence should be preserved.
Process for analyzing logs, documentation, and other evidence to perform a root cause analysis.
Change control process for implementing necessary changes or for approving emergency changes.
Outages need to be tracked, including impact to service levels, the outcome of the root cause analysis, and the actions taken to resolve the outage. Outage reports should be stored in a standard format and location so they can be reviewed to look for patterns on how to improve the reliability of the environment.
Because policies bind the organization, they need to be approved at a level that will be recognized. A lot of organizations have to provide evidence of compliance with policies as part of audits. This involves setting up controls and investments of capital and staff time to maintain the controls.
Because most organizations have regulatory and contractual requirements that they have to comply with anyway, it makes sense to have policies that reinforce compliance.
There are several constituent groups within the organization that need to approve a policy for it to take effect.
Depending on the nature of the policy, the legal or compliance department may need to review the proposed policy to make sure it meets regulatory or contractual requirements.
The architecture team needs to review the policy and possibly raise flags about the costs required to change the technology landscape to make compliance possible. The technology teams who would implement the policy need to review it to raise flags about additional costs or requirements that will be needed to support the policy.
Management needs to review the policy to decide if it represents a business priority and if the proposed policy reflects the organization’s goals.
The approvals for a policy need to happen at a sufficiently high managerial level that the policy’s legitimacy will be recognized by all the relevant teams.
Once a policy is approved, it needs to be published. Organizations should have a standard way to store, approve, and communicate policies. If policies are not published in a standard location, people will not be able to refer to them to comply with them.
Policies are supported by standards and procedures. Part of the approval process for a policy has to include drafting and approvals of these standards and procedures. But there is no need to have those standards and procedures approved by upper management.
In some cases, it may be appropriate to refer a new standard or procedure to the compliance team, but the technology architecture and implementation teams usually control things at that level. Just as most technology people are not lawyers, most lawyers are not competent to judge technology.
Sometimes technologists see standards as confining. When an enterprise standard exists, sometimes that means that the absolute optimal solution for a particular problem cannot be found.
Ideally, standards should be liberating. If there is a standard way to roll out large parts of the technology infrastructure, it will help the operations teams maintain the technology, as it reduces the number of platform issues that need to be tracked and resolved.
It will help the development teams because templates and code libraries are able to be re-used. And it will produce a better overall environment because standards promote more efficient, reliable functioning of the environment.
Documentation is the key to mature, effective, repeatable processes. Effective procedures are documented, followed, and updated. Learning to manage documentation effectively will be key to your long-term success as a manager.