ITProject Management

PROJECT MANAGEMENT SKILLS & CERTIFICATION OPTIONS
These are changing times for the IT profession. There has been a tangible shift in the
"professional skills" landscape over recent months and years, largely due to outsourcing,
evolving technology trends, and other economic factors. Data from the Bureau of Labor
Statistics shows a continuing decline in traditional IT employment (i.e. programmers and
tech support analysts), and a corresponding growth in management positions, including
project managers.
It has become increasingly clear that "project management" is essential to any long term
career in information technology. While IT management certainly has its share of pure
operational components, so much of what goes on in the IT environment can be classified
as a "project".
Project work is defined by a series of common characteristics, with details that vary
according to each project:
Unique outcomes (deliverables).
Specific start and end dates.
Scheduled path (tasks, events and activities)
Assigned resources (people, equipment, budgets).
Risks, constraints and assumptions.
What is project management?

According the American Society for Quality, project management is defined as "The
application of knowledge, skills, tools and techniques to a broad range of activities to meet the
requirements of the particular project...."
As these definitions show, project management expertise and ability exists at multiple
levels, forming the "PM proficiency portfolio":
The PM Proficiency Portfolio
Knowledge
The degree of familiarity with project management theories and

practices. Project management knowledge will vary according to
level (basic and advanced). Basic knowledge involves familiarity
with accepted principles of project management for project
initiation, planning, execution, control, closure and review.
Advanced knowledge involves familiarity with specific academic
and industry standardized methodologies (i.e. PMBOK, Six Sigma,
etc.)
Skill
The ability to execute project management responsibilities to

produce successful projects. Hard Skills: project definition,
planning, documentation, scheduling, budgeting, risk planning,
issues tracking and progress measurement. Soft Skills: leadership,

communication, negotiation, delegation, time management, conflict
resolution, and team motivation.
Tools
The ability to use available project management tools (software) to

manage projects and produce successful results. Project management
software products range in purpose and complexity, from single
project lifecycle management to project portfolio management.
Obviously, certain products have gained more widespread usage
than others (i.e. Microsoft Project). Tools "capabilities" can be
measured in the familiarity with features and functionality, including
project set-up, data entry, data maintenance, and reporting.
Techniques
The ability to apply knowledge, skills and tools in appropriate

proportions to meet varying project needs and circumstances (size,
duration, complexity and value. Technique is reflected in the ability
to manage different types of projects, recognizing that one project
approach will not "fit all".
Building Your Portfolio....
Education and experience form the backbone of the PM Proficiency Portfolio, and
professional certification provides "external" verification of said skills and capabilities.
Certification has played an important role in the IT profession for a number of years,
particularly for technical specialties. Currently, there are two primary sources for "project
management" certification: CompTIA and PMI. The chart below compares the two:
CompTIA
Project Management
Institute
The Computing
Technology Industry
Association
(CompTIA) provides
certification in
multiple subject
Overview areas to IT
professionals.
Project management
certification is
provided at one
level, known as
Project+
The Project Management

Institute (PMI) provides
project management
certification for IT and
non-IT professionals.
Certification is offered at
two levels: Certified
Associate (CAPM) and
Project Management
Professional (PMP).
Requirem
Single Exam
ents
Combined requirements of
formal education,
experience, training and
exams.
Longevity
Lifetime
Certification
Certification relies
on (4) subject areas:
(1) Project Initiation
& Scope Definition,
(2) Project Planning,
Structure (3) Project
Execution, Control,
& Coordination, and
(4) Project Closure,
Acceptance &
Support
Initial certification valid for

three years, with continuing
requirements to maintain.
Certification relies on (9)
subject areas: (1)
Integration Management,
(2) Project Scope, (3) Team
Management, (4) Cost
Management, (5) Quality
Management, (6) Human
Resources Management,
(7)Communications
Management, (8) Risk
Management and (9)
Procurement Management.
Available since 2001

Acceptan
(acquired from
Available since 1984.
ce
Gartner).
Testing & Varies by
Applicati membership status
on Costs (approx. $200+).
Varies by membership
status and certification
level (approx $225 $500+).
The "to certify or not to certify" decision depends upon multiple factors. Certification
adds credibility to any resume, providing a starting point for anyone lacking substantial
project management experience or formal education. The PMP certification has been
around for a long time and has widespread industry acceptance. However, the
requirements are more stringent and require familiarity with PMI's PMBOK (The Project
Management Body of Knowledge).
The CompTIA certification is a relative newcomer in the field compared to PMI, but the
requirements are more favorable to the project management novice. In short, the
certification "selection" will depend upon individual needs and circumstances, including
career goals, current project management experience, time, and demand (which
certification will better suit employment opportunities in your area?)
Where do you stand?....
In order to maintain your place in the IT employment landscape, you must keep a
constant eye on your skills portfolio. If project management skills are in demand, do your
skills stack up? As you evaluate your PM Proficiency Portfolio (knowledge, skill, tools,
and techniques), the following questions must be addressed:
How would you describe your project management training? (formal or self-taught)?
How would you describe your hands-on project management experience (substantial,
moderate, minimal)?
What is your current level of project management knowledge (expert, intermediate or
novice)?
What is your current level of project management skill (expert, intermediate or
novice)?
Are you able to use industry standard project management software?
If so, what is your current level of expertise for each software tool (expert,
intermediate or novice)?
What is your project track record in terms of the number and type of project (varying
by purpose, size, complexity, duration, and value)?
What type of roles have you filled in these projects (manager, team leader or team
participant)?
Considering this project track record and roles played, how well have you applied
your knowledge and skills to form effective project management techniques?
Are you currently capable of managing different types of projects and/or multiple
concurrent projects?
Is your current PM Proficiency Portfolio based more on hands-on experience,
education, or equally on both?
Make career decisions accordingly.....
As you run through these (9) questions, you will be able to identify portfolio strengths
and weaknesses. For example, you may be a self-taught "project manager, relying more
on experience than formal education. Or, you may have little practical experience with
projects, but have recently completed training courses. This "focus" must be placed in
context of the current employment landscape as you plan your next career move, or
commit to additional training and/or certification spending.
What are your career necessities (i.e. the skills are needed to remain gainfully
employed and competitive in the professional marketplace)?
What types of employment opportunities are available to you according to level
(senior, intermediate, entry) and environment (corporate, government, mid-sized
business, or small business)?
How is your current PM Proficiency Portfolio suited to these available opportunities
(by level and environment).
How can you take advantage of your portfolio strengths?
How can you compensate for portfolio weaknesses (i.e. take on additional
responsibilities at work, certification, training)?
Related Quick Tools:

The Project Experience Checklist
Use this planning Quick Tool to help you evaluate and document your hands-on project
management experience. This Checklist can be used for skills evaluation, career
planning, interview and resume preparation. Complete a separate form for each of your
current and past projects.
HOW TO IDENTIFY BUSINESS BENEFITS FOR PROJECTS &
PROPOSALS
Every IT proposal should be backed up by one or more business benefit. To ensure that
every technology proposal is considered and hopefully, accepted, these benefits need to be
realistic and relevant.
The IT organization is often called upon to make decisions and to take responsibility
for the secure, reliable and effective operation of technology within business.
Depending upon nature of the business and role of the IT function, these decisions
and responsibilities can include the selection, installation, maintenance and support
of a varied array of technical platforms - hardware, software, networks, peripherals
and communications systems.
In order to make effective decisions, realistic, relevant business benefits must be identified
and quantified. This is necessary just to ensure that the best choices are made, but is it is
critical to ensuring the acceptance of those choices by management and end-users.
This checklist can be used to identify and consider business benefits ... to make sure
that you cover all the bases and consider all the angles.
THE BUSINESS BENEFITS CHECKLIST:
Use this checklist as a guide whenever you are preparing a proposal or business
justification, to ensure that you are able to identify and explain all potential business benefits.
These benefits are varied, and can apply to any IT initiative ....
The implementation of new technology....
Upgrade or migration of existing technology....
Change in policy or procedure....
Organizational changes....
Process re-engineering.....
Financial Benefits:
___ Increased revenue opportunities

___ New revenue opportunities
___ Increased profitability for products and services
___ Greater return on investment
___ Offers tax advantages
___ Offers expense reduction opportunities
___ Lowered production costs
___ Offers increased cash flow opportunities
___ Increases shareholder value
Organizational Benefits:
___ Promotes company reputation or market position
___ Create new market opportunities
___ Improves customer service opportunities and obligations
___ Allow the company to be more competitive
___ Promotes company values and strategic decisions
___ Fulfills regulatory or legal requirements
Operational benefits:
___ Increased productivity
___ Improved workflow
___ Saves time
___ Facilitates internal or external communication
___ Reduces staff requirements
___ Reduces training requirements
___ Eliminates or reduces the need for external resources
___ Simplifies procedures through ease of operation
___ Provide ergonomic or environmental advantages
___ Makes better use of available workspace
Technology Benefits:
___ Maintains or improves systems reliability
___ Maintains or improves systems security

___ Maintains or improves systems performance
___ To keep systems current in terms of configuration or version
___ Protects current investment in technology
___ Lowers technical support costs
___ Facilitates technical support activities
___ Meets Service Level Obligations
___ Facilitates systems utilization - improving ease of use
CONCLUSIONS......
Once you have can justify and quantify technology decisions in terms of tangible business
benefits, you will be in a better position to submit meaningful proposals, with a higher
probability of success. And, if your proposals are not approved, at the very least, you will
have gained important insights into business needs and priorities.
Ideas into Action:
The following tools will help you apply these "business benefits" principles to your
environment:
The Software Evaluation Matrix (Quick Tool)
The IT Value Evaluator (Quick Tool)
MORE ABOUT IT:
The Business Benefits Planning Checklist: a click-in-the-blank planning worksheet to
help you identify and communicate business benefits for your technology projects and
proposals. You can use this tool to identify and prioritize benefits, estimate costs and
savings, calculate payback, and draw conclusions.
Project Initiation....
The Project Planning Roadmap
Jumpstart your projects with a timely definition of requirements and deliverables, as you take
positive steps towards success with a careful analysis of key planning variables. Using the
pre-formatted roadmap template, you will quickly define and document a complete project
vision, getting your projects off on the right track.
Disaster Recovery Planning......
The Disaster Recovery Plan Process Kit
An essential tool for practical, "nuts and bolts" disaster recovery planning. Taking a
"consequences" approach, this valuable learning tool and "take action" resource will help
you to respond to multiple types of technology related disasters - from virus incidents to
hurricanes.
Proactive Problem Management........
The Problem Management Policy Kit

Proactive problem management is the key to IT service quality. Using the Kit you will learn
how to build a problem response "safety net", helping you to solve problems and serve
customers.
HOW TO MANAGE THE PROJECT SELECTION PROCESS

The project selection process should be designed to ensure that project proposals are evaluated
fairly and objectively, with a focus on business value and project viability.
Every project begins with a proposal, but not every proposal can or should become a project. In
a world of limited resources, choices have to be made. Not every project has viability. And,
amongst those that do, limited resources (people, time, money and equipment), must be applied
judiciously. Consider the risks if resources are misapplied:
Resources are "used up" before projects can be completed.
Resources are wasted in projects of lesser value and priority.
Credibility and influence are lost as perceived project failures pile up.
To maximize available resources, and avoid potential failures, project proposals must be
evaluated and selected on the basis of overall viability. In a business sense, project viability is
the degree to which a given project will provide the expected return on investment. Viability can
be measured by three key variables:
Value: The project must provide measurable benefit to the organization, in terms of revenue,
cost reduction, productivity, or some other desired result.
Alignment: The project must be consistent with, and supportive of, overall business goals and
objectives (including technology goals).
Probability of Success: The project must present a realistic opportunity for success, relating to
outcome and process, and as can be measured by business, project management, and
technology standards.
Project Selection in Perspective....
Project selection is all about viability, and some projects are more viable than others - hence, the
choice. It can be said that viability exists at two levels:
Level 1: Individual Viability. The degree to which a proposed project is viable as an

independent initiative. (Does the potential project provide value, is it in alignment with
business goals and objectives, and is it "doable"?). A lack of individual viability will lead
to proposal rejection before comparative is even considered. (If a project can't stand on
its own, it should not stand with others...)
Level 2: Comparative Viability: The degree to which an individual project retains its
viability when compared to other projects. Considering resource limitations, comparative
viability will determine project selection priority.
In order to meet the practical realities of project selection, any supporting process must allow for
proposal consideration at each of these levels. First, the project pool requirement must be
addressed - allowing for the submission and review of multiple project proposals according to a
pre-defined schedule. In addition, the project selection process must also allow for the
unscheduled, as-needed submission of individual project proposals.
As the project selection process is developed, the following questions must be considered....
Project Pool Considerations:
1. How will project proposals be submitted into the "pool" of potential projects?
2. How often will the project "pool" process be undertaken (yearly, quarterly,
monthly)?
3. Who is responsible for managing the project "pool" selection process?
4. How will project proposals be reviewed and evaluated?
5. How will selection decisions be made?
6. How will selection decisions be approved?
7. How will selection decisions be communicated?
8. How will disputes be resolved?
As-Needed Submission Considerations:
1. Who is responsible for the review of "as-needed" project proposals? (e.g.
project selection committee, company management, line of business
management, individual business units.)
2. How will as-needed project proposals be submitted?
3. How will as-needed project proposals be reviewed and evaluated?
4. How will selection decisions be made?
5. How will selection decisions be approved?
6. How will selection decisions be communicated?
7. How will disputes be resolved?
In order ensure that these questions are addressed, the project selection process must contain
the following structural elements:
Organization
Goals & Objectives
Deliverables
Roles & Responsibilities
Steps
Standards
Process Component #1: Organization
Any effective project selection process must rely upon a pre-defined "organizational"
hierarchy for proposal review and selection. This organization will likely take a
"committee" structure, allowing for a sufficiently diverse membership, designed to
ensure that all "perspectives" are considered as projects are reviewed (e.g. business
management, project management, finance, human resources, technology, etc.). In
addition, the project selection "organization" must also account for "as-needed" project
evaluation, where formal committee review may be too cumbersome and ineffective. In
these cases, project approval can be farmed out to a committee sub-set (by expertise
or business area), or to individual line of business management.
Tip: Establish thresholds for project selection - e.g. small projects can be "selected"
outside the formal committee organization.
Process Component #2: Goals & Objectives
The project selection process must be designed to meet certain key goals and
objectives:
To evaluate proposed projects according to a set of pre-defined criteria.
To weigh proposed projects and make appropriate selections based on

comparative viability.
To engage in a collaborative process with all process stakeholders to ensure

that all relevant information and perspectives are considered.
To review, approve and/or reject project proposals in a timely manner.
To communicate status, issues, conclusions and justifications in an open and

timely manner.
Process Component #3: Deliverables

The project selection process must rely upon, use, and produce specific project
selection deliverables. In order to facilitate the process, these deliverables should have
a pre-defined format:
Project Proposal: To provide basic project information, and activate the

selection process (pool or individual).
Business Case: To provide the business justification needed to support

proposal acceptance.
Project Review Scorecard: To evaluate the proposal according to pre-defined

criteria, providing an objective review of the proposal on the merits.
Selection/Rejection Notification: To document and communicate the results

of the selection process.
Process Component #4: Roles & Responsibilities

The project selection process must specify the various "roles and responsibilities" to be
assigned to process participants and stakeholders:
Management - to lead the process as project proposals are received, reviewed

and evaluated.
Participation - to complete assigned tasks for proposal submission, review,

analysis, input, and disposition (selection or rejection).
Support - to promote the process within the organization.
Process Component #5: Steps

The project selection process should contain a series of defined steps, combined in
sequence, with appropriate decision checkpoints.
1. The project "Proposal" is prepared and submitted, along with a "Business
Case" if needed.
2. The "Proposal" and "Business Case" are evaluated for sufficiency (i.e. Do these
documents provide the information needed to evaluate project viability?). If not,
the items should be rejected for further edification and revision.
3. The "Proposal" and "Business Case" are reviewed and evaluated according to
the pre-defined criteria. The extent of the "evaluation phase" will vary based on
the whether this proposal is under review individually, or as part of the proposal
pool. Evaluation tasks typically include the review of proposals by one or more
individuals, documentation of the resulting scoring and ranking decisions, and
discussion of these tasks and deliverables in a collaborative setting. See: The
Project Selection Scorecard
4. Project selection choices are made (e.g. project proposals are approved,
rejected or put on hold).
Process Component #6: Standards
The project selection process must specify the standards by which project proposals
will be evaluated and selected. These standards should be designed to address these
four requirements:
Priority: The "discretionary" nature of the project proposal. Some projects will
be mandatory, and others must compete for viability and resources. Projects of
a higher priority will set the "pace" for project selection.
Criteria: The specific characteristics for viability measurement.
Score: The "degree" to which the various criteria are met (or not met).
Weight: The comparative ranking of multiple project proposals.
Conclusions:
The goal of the project selection process is to analyze project viability, and to approve or reject
project proposals based on established criteria, following a set of structured steps and
checkpoints. This type of structured process offers several key benefits:
Sets useful standards to guide decisions.
Fosters "challenge" thinking (i.e. to review project proposals with a critical eye).
Saves time and minimizes redundancies.
Minimizes knee-jerk responses to project requests.
Promotes cooperation and collaboration.
Provides a "big picture" perspective, providing context for proposal review.
Promotes priorities, ensuring that resources are applied to projects as needed and based
on the expected "return on investment".
As a final note, it is also important to keep the process in perspective. The project selection
process must be tailored to suit the needs of the organization and the types of projects faced.
Obviously, large scale, enterprise projects must be reviewed and selected via a formal process.
As project size and scope diminishes, process formality can be scaled appropriately, but basic
process principles must always apply.
Whether your projects are large or small, every project must make business sense. A well
planned selection process will help you achieve that goal.
IT MANAGEMENT WORKBOOKS:
positive steps towards success with a careful analysis of key planning variables. Using the preformatted roadmap template, you will quickly define and document a complete project vision,
getting your projects off on the right track.
"consequences" approach, this valuable learning tool and "take action" resource will help you to
respond to multiple types of technology related disasters - from virus incidents to hurricanes.
Proactive problem management is the key to IT service quality. Using the Kit you will learn how to
build a problem response "safety net", helping you to solve problems and serve customers.
Customer Satisfaction Surveys.......
The IT Services Survey Kit
End-user feedback is essential to IT success. Using the Kit, you will survey end-users, analyze
results and apply valuable lessons learned, taking steps to improve IT services and relationships.
BREAK IT DOWN: HOW TO CREATE PROJECT DEFINITIONS

In order to deliver any successful project, that project must first be broken down into smaller,
manageable parts. Taken as a whole, no project could ever be completed --- the task would just
be too massive and undefined. For that reason, projects must be broken down into elements that
take the theoretical ---- i.e. we need a new accounting system, into the practical ..... who is the
system for? .... what does it need to do? .... why do we need it? ..... how do we build it?.... and
when does it need to get done?
These elements define a project, turning an idea and a desire into concrete objectives and steps
that can be planned, managed, measured and controlled. The process of breaking a project down
into manageable components is the most basic element of project management. And effective,
realistic project definitions are essential for overall project success.
Project definitions should address three key categories....
Goals, Scope, Deliverables and Success Criteria: providing purpose and direction...
Phases, Tasks and Activities: establishing what has to get done and when it must be
completed....
Processes and Procedures: establishing the internal mechanisms for implementation and
control...
1. Goals, Scope, Deliverables & Success Criteria:
Providing purpose and direction, the identification of goals, scope and deliverables is the starting
point of any project .....
While these terms are often used interchangeably, each one does have a specific place in the
project definitions chain....
Goals: Every project should have a specific set of goals and associated benefits.... what are you
trying to accomplish, and why? The right set of goals can ensure that your project suits a true
business purpose, and it creates a common purpose.
Scope: Project scope can be defined as the body of work (overall tasks, activities and decisions)
that must be completed in order to ensure that project goals and deliverables are met. Scope
should be clearly defined and limited to the work that must be done to meet the goals at hand.
Deliverables: Project deliverables can be defined as the tangible result or outcome of a given
project, whether physical (hardware, software...) or logical (performance improvements, policies
and procedures, etc....)
Success Criteria: Project success criteria are needed to establish consensus amongst project
participants (managers, staff and end-users) as to the definition of success, establishing the
terms for acceptance and minimizing the risk for false expectations. When defining success
criteria, you need to consider all project elements ....results, process, budget and timeliness.
Success is not one-dimensional, and you may be able to achieve "success", even if all project
elements are not met to everyone's satisfaction.
Whether you choose to mingle these definitions or not, any specification of goals, scope,
deliverables and success criteria should be....
Explicit and unambiguous: to clearly state requirements and establish common

purpose and understanding....
Measurable: so that results can be quantified....
Relevant and realistic: to ensure that results can be attained and are in synch with
business needs.....
Time specific: establishing deadlines for completion and progress measurement....
Controllable: so that progress can be monitored and changes controlled....
2. Phases, Tasks and Activities:

While your initial project definitions will establish "what you are trying to accomplish and why you
are doing it", phases, tasks and activities will define what you need to do to get the job done....
As you define phases, tasks and activities for any project, you should keep an eye on the criteria
listed above .... ensuring that each element is specific, attainable, measurable and time
dimensioned. While there are many techniques out there for task specification and estimation,
practical experience usually provides the most useful guidelines and reference points.
Whenever you begin a new project, it is wise to look to past projects for similarities and lessons
learned......
How long have similar tasks taken in the past?
How have similar projects been organized and scheduled?
What resources were required for completion?
What improvements can be made based on past experiences?
Using these four questions as a starting point, project phases, tasks and activities can be defined
via the following five categories....
1. Identification: the specification of the tasks and activities needed to execute and
complete the project while delivering the expected results. Tasks specify the work that
has to be done, and activities are used to support the completion of any such project
tasks. For example, a task may be specified as "building a file server", while an activity
would be "attending a meeting to discuss building the file server". As a rule of thumb,
tasks and activities should be broken down into manageable sizes, so that they can be
assigned, scheduled and completed. In general, tasks should be sized according to a
"40" or "80" hour rule, so that they can be more readily completed and monitored.
Activities should be limited to frequency and duration as is needed to complete the
project. And, when in the process of task identification, you will also need to identify
"milestones" - i.e. the key tasks you will look to as an indicator of ongoing progress and
success.
2. Organization: structuring tasks and activities into project phases, providing project
shape, flow and overall vision.... Most technology projects do occur in phases, allowing
for optimum management, particularly when multiple projects are underway. The use of
phases allows you to view a project as a series of distinct initiatives working towards an
overall goals. Commonly used phases can include Requirements, Design, Development,
Pilot, Implementation, and Post-Project Implementation.
3. Sequencing: placing phases, tasks and activities into a sequence designed to meet a
specified deadline. To properly sequence tasks, you need to consider duration (how long
a task will take to complete), and overall scheduling (assigning a start and end date), as
well as task relationships and interdependencies. (Critical Path, Parallel Tasks, and
Dependencies).
Project Scheduling Strategies
4. Allocation: the process of assigning tasks to project teams and individuals according to
skills, expertise, and available resources. When allocating tasks you need to consider
who has the skills to complete a given task, how much authority you will need to delegate
to get the task done, and the number of resources available considering other projects
and existing workload. Assigning Project Roles and Responsibilities
5. Prioritization: In theory, projects are planned, and are then executed according to that
plan. Reality tells a different tale... projects must change as business needs and
circumstances dictate. A project is a living, moving event, and in order to respond
properly to changes and problems, project tasks and activities should be properly
prioritized, allowing tough choices to be made. Individual task priorities can be viewed in
terms of their impact on overall project goals and deliverables.... i.e. critical, important,
nice to have.... Viewed in these terms, tasks can be more readily selected for elimination,
restructuring or re-assignment.
Processes and Procedures:
The best definitions of goals, deliverables, tasks and phases can all come to naught without
effective processes and procedures for management and control. Once a project begins, it takes
a good deal of effort to stay the course. To meet this essential project management goal, you
should not embark on any project unless you are prepared to deal with certain basic management
issues.....
Communication: to ensure effective utilization of meetings, status reporting, and

information flow...
Change control: to facilitate change requests and avoid creeping scope....
Progress measurement: to establish criteria for measuring progress and keeping a

project on track....
Risk management: to identify and manage risks to project completion and success....
Budget management: to keep project costs under control, and to reallocate project
funds as needed to resolve problems and react to changes....
Staff management: to maintain sufficient staffing levels, team participation, and

appropriate reporting relationships to ensure that your project can be completed on time
and as needed....
Transition management: moving project results to ongoing, operational status....
CONCLUSIONS.....
The right set of project definitions can give your project the start it needs .... at the very least,
these definitions create a framework for project completion, and establish a common level of
understanding for project participants. While changes will probably occur along the way, effective
project definitions will create a strong basis for future actions. Even if your project is small, you
should take the time to ensure that all your planning bases are covered with a thorough set of
project definitions.
Related Workbook Products from ITtoolkit.com:
The Statement of Work Process Kit

You can't plan what you can't define. To avoid costly mistakes and frustrating recriminations,
projects must be clearly defined from the outset, and steps must be taken to ensure that all
stakeholders and participants share the same vision. The Statement of Work Process Kit gives
you a complete system of steps and tools to define and document your "project vision", wrapped
up in an easy five-phase workflow.
The Project Planning Roadmap NEW VERSION!
Practical advice to get your technology projects off to a timely, consistent start.....
A pre-formatted project planning template (in Microsoft Word format) filled with multiple
"click-in-the-blank" questions designed specifically for streamlined planning and analysis.
And, it's all backed up by ready-to-use guidelines and definitions in nine key categories,
supporting project planning and roadmap preparation.
Project Planning: The Really Creative 1st Step

Project managers are typically task-oriented people with a strong sense of urgency and a keen focus on
getting started and finishing. Not too surprisingly, the inclination of most PMs is to skip strategic project
planning and start work. In our AdPM methodology, we teach PMs planning techniques that unearth
measurable business outcomes. We use those outcomes to build an achievement network that makes all
our deliverables crystal clear. But not everyone uses AdPM techniques.
The Activity Trap

Instead of defining the measurable results, many PMs and their sponsors focus on the bells and whistles of
the project's tasks. This is the activity trap, and it is an evil thing. When a PM dives head first into the gunk of
the activity trap, the project planning takes the form of horse-trading. "Okay, if you can add your favorite
task, then I get to add mine!" Most importantly, no one has agreed on what the project will achieve.
After the project starts, tasks can change at the drop of a hat because there is no clear vision of the end
result; everyone has their own idea. The project's scope and budget expand wildly as tasks are added
because they sound like they should be part of the effort. The inevitable budget cutting is equally senseless.
The thousands of decisions that people make during a project are not channeled toward a clear, measured
result. The project manager doesn't find out about this desired strategic result until the project is almost
finished and the stakeholders are unhappy.
It's no surprise that most bad projects -- particularly the ones that organizations repeat every few years -- are
flawed because the front end planning is weak or was never attempted. It's up to the project manager to get
the real definition of success before the project starts.
The PM must ask tough questions of the project sponsor and stakeholders: How will you measure success
at the end of this project? What do you really want to buy for all this money we're going to spend? Getting
answers to these questions forces the kind of conceptual thinking required at the front end of a project.
Without an understanding of the desired result, the PM cannot fend off scope enlargement and define
success for the people who will be doing the work. With answers to her strategic questions, the PM can
drive the project toward the agreed upon measures of success.
A Different Kind of Thinking

Defining project success before you start requires conceptual thinking. We need to conceive a project as a
linked chain of measured achievements. We create this chain by starting at the end of the project -- yes, the
end. The last achievement is the sponsor's definition of success. This success definition needs to be
measurable and preferably quantifiable.
"Provide the best possible customer service," is neither. Sure it sounds good and no one will
disagree, but it's mush. We can't measure whether or not we have achieved this.
"Answer 95% of our customer's calls within 120 seconds," is measurable and quantifiable. People
will argue about whether this is what they want and that's the point; we want to define good
customer service before we start the project.
After a sponsor "buys off" on this second definition of success, we will not have to argue about whether or
not we succeeded. Let's go back and look at how a PM would develop this measure of success using this
customer service example. As the PM, you're assigned a project which the sponsor describes as consisting
of a new information system, training and installation for a customer service division that answers telephone
inquiries. Immediately, you find yourself deluged with the technical details of hardware, programming and
training that the new customer service system requires. As challenging and important as these are, they are
only activities.
The success definition is not to install hardware and software. The success definition must be a strategic
result. The sponsor wants to talk about activities. As project manager, you need to force a discussion of
what the end result will look like in terms you and the sponsor can measure. After long discussions, you may
finally unearth that the sponsor's real desire is to reduce the number of times that a customer problem is not
solved on the first call.
Now we're getting someplace. You and the sponsor work out the measurement process and come up with a
tight success measure like the one we had above; resolve 95% of all customer problems during the first call
(i.e., no call backs or second calls about the same problem). Of course, finding out how stakeholders will
measure a project's success at the end is not an easy task. The measurement is never just a budget and
due date. Often the project's sponsor doesn't know how he will measure success and the PM and sponsor
are both easily snared in the same activity trap. Focusing on activities, the PM would not discover what the
sponsor really wants to "buy" until the project is complete, and stakeholders and sponsors express their
disappointment.
The Reluctant Sponsor: Where The Politics Come In

For all the above reasons, the seasoned PM realizes that it's foolish to start a project until the sponsor has
defined success in measurable terms. Some sponsors resist providing this definition of success. Doing so
requires that they commit to exactly what they want. This is politically risky for them. Getting a clear
definition of success also requires that you reconcile the conflicting desires of various stakeholders in the
project.
While this process is difficult, it's far easier to handle these stakeholder conflicts before you start than to
have them plague you and your project team for the entire duration of the project. In sum, completing the
front end planning of a project is no easy task. It usually involves pressing people who outrank you to make
difficult conceptual decisions. It requires that you engage in "blue sky" thinking and that you resolve the
conflicts between project sponsors. But the benefits are substantial. You can control project scope by asking
the question, "How does this new task you want to add help us reach our measure of success?" You can
give your project team crystal clear expectations about what they have to achieve. Finally, you do not have
to argue about what people really want during the project or, even worse, at the end.
HOW TO CALCULATE "QUALITY MANAGEMENT" OVERHEAD

Quality management cannot guarantee project success, but it certainly provides a force against
failure. Quality management goes straight to the heart of any project, helping you to deliver
results designed to meet customer needs and expectations. The goal of effective quality
management is to set realistic project and process quality objectives, define actionable quality
expectations, ensure minimal product defects and eliminate re-work. In short, quality
management is designed to help you deliver the best project results within established constraints
and boundaries.
Effective quality management offers any number of tangible and intangible benefits:
Quality management helps you to produce deliverables designed to meet business and
technical needs.
Quality management helps you to increase customer satisfaction and build confidence
in project solutions.
Quality management helps you to avoid quality defects and the associated costs,
including expensive re-work, and the related repair, support, maintenance and product
replacement costs associated with low quality deliverables.
Quality management helps you to decrease errors and increase ROI by extending the
use and lifespan of project deliverables.
Quality management helps you to build project team confidence and morale as
products are delivered and customers are satisfied.
This is an impressive list, but, as with any other management process, quality comes at a price.
Quality management adds to the cost and timeline of any project through "overhead". Overhead
can be simply defined as the direct and indirect costs attached to a project as part of the overall
execution process ... i.e. the time, resources, tools and equipment needed to manage and deliver
a project apart from the costs of the actual project deliverables.
Quality Management Overhead Variables:
Time: Quality management activities will elongate the project schedule with the addition
of tasks and deliverables required for quality planning and control.
Resources: Quality management activities will require additional resource hours to

execute quality planning and control tasks and produce related deliverables.
Tools & Equipment: Quality management activities may require certain tools and
equipment (hardware, software) to execute quality control (testing) tasks and produce
related deliverables.
Since quality management overhead adds to the costs and delivery timeline of any project,
overhead can be considered a potential point of failure. Left uncontrolled, overhead can impede
an otherwise successful project by extending the schedule or growing the budget. It is all a matter
of balance - to find the point at which quality objectives are achieved and defect risks are
avoided, without exceeding acceptable budgets and schedules. As with any other process,
quality management must be applied appropriately considering project needs and
characteristics.
Strike the Overhead Balance:
1. If quality requirements and expectations are not achieved, what are the likely costs and
consequences?
2. What types of quality management tasks and activities can be used to minimize or
eliminate these "low quality" consequences?
3. How will these quality management tasks and activities add to the project budget and
timeline?
4. Are these "overhead" additions acceptable to the project sponsor and customers, or, are
these stakeholders willing to absorb certain "quality defect" risks for the sake of a shorter
timeline and lower budget?
Step by Step: Quality Overhead Calculation
Step 1: Evaluate project needs and circumstances.
At one level, quality should be a constant regardless of project size, scope or impact. But, in the
real-world of projects, time is short, budgets are tightly controlled, and choices must be made.
Quality management tasks and activities must be sized to suit the needs and characteristics of
the project at hand. Obviously, a large, complex and highly visible project will require more
extensive quality management activities than a smaller, less strategic project. In addition, any
attempt to apply overly formal, time consuming procedures to a small project, just for the "sake of
process", will likely have negative consequences. As quality management is planned, the
following project parameters must be considered:
Project Visibility: The extent to which the project has a high profile within the
organization. (Highly Visible = More QM)
Project Value: The ultimate value of the project to the organization in business and
technical terms. (Higher Value = More QM)
Experience: The level of experience that the project team has in producing the expected
deliverables. (More Experience = Less QM)
Size and Complexity: The overall size and complexity of the project in terms of
duration, number of tasks, and degree of difficulty. (Large and Complex = More QM)
Step 2: Establish your quality management goals.

Without considered analysis, quality can be too often pigeon-holed into a singular definition of
"zero defect". But as discussed in Project-Speak: Quality Management, quality exists at many
levels and in many shades of gray. This presents a quality quandary ..... should quality goals
be set for perfection (i.e. zero defect) or should compromise rule the day? In most cases,
compromise is a reasonable response to the demand for quality, countered by the demand for
quick project delivery and low project overhead. The quality compromise seeks optimum quality
results based on timing requirements, costs, resource capabilities, and competing interests.
Step 3: Identify quality management task, tool and resource requirements.
What tasks, tools and resources are required to plan and execute each of the following quality
management "process elements"?....
Quality
Management
Planning
To name the tasks, tools and resources needed to plan quality

management procedures for any given project.
Result: Quality Management Plans
To name the tasks, tools and resources needed to identify quality

Quality
requirements and expectations.
Specifications
Result: Quality Specifications Documents
Quality
To name the tasks, tools and resources needed to obtain and
Consensus
document all quality management deliverables.

Result: Approved Quality Specifications, Plans, Tests, and related
Change Documents
Quality
Control
To name the tasks, tools and resources needed to control, test

and manage quality as project deliverables are planned and
produced.
Result: Manual Reviews/Tests, Automated Reviews/Tests,
Prototypes, Pilot Programs
As these tasks, tools and resources are considered and planned, the following issues must be
addressed as a basis for the cost analysis in Step 4 below:
Frequency: How often will the required tasks, tools and resources be executed and
applied as the project is planned, managed and executed? (higher frequency will add to
overhead costs)
Complexity: What are the detail, format and complexity requirements for each of the
required tasks, tools and resources? (higher complexity will add to overhead costs)
Step 4: Estimate quality management overhead costs and consequences considering

frequency and complexity requirements.
At this point, overhead costs must be estimated for the selected tasks, tools and resources using
the following variables:
Schedule Impact: How much time must be added to the project schedule to
accommodate planned quality management tasks, tools and resources?
Resource Costs: What are the additional resource costs (hours x rate) associated with
these planned quality management activities?
Tools and Equipment: What are the costs (acquisition, rental, fees, etc.) associated
with the tools and equipment needed to support planned quality management activities
(hardware and/or software).
Step 5: Negotiate and achieve stakeholder acceptance.

Once quality management overhead costs are calculated, all project stakeholders must be fully
informed. In order to strike the appropriate balance between process and acceptable overhead,
the project sponsor and customer must accept the risks of any "quality compromises" made in an
attempt to shorten project timelines, minimize process complexity, or lower project costs. Quality
management procedures must be appropriate to project needs, and designed to deliver quality
goals and expectations. Since quality is subjective, sponsor and customer buy-in is essential to
project success.
Related Quick Tool: Quality Management Overhead Worksheet
IT Management Workbooks:
PROJECT OUTSOURCING: BY CHOICE OR NECESSITY?

How to evaluate outsourcing options.....
Projects may be outsourced for any number of reasons, either by choice or necessity. But one
thing is clear outsourcing does not equal simplicity. While outsourcing may eliminate certain "inhouse headaches", the added "outsourcing overhead" creates a new layer of complexity and
responsibility for the internal project manager. Just consider these examples:
When you outsource a project (in part, or as a whole), you will have to.....
Make the outsourcing decision.
Find the right contractor/consultant.
Negotiate and manage proposals, bids and contracts.
Rely on an external operation where you have little influence.
Clearly define the "vision thing" (you wont have the luxury of internal familiarity and
"cultural" assumption).
Manage an administrative overhead for accounts payable purposes.
Educate the contractor/consultant on internal procedures, goals and operational

requirements..
Track project progress without direct authority, relying on project staff that may not be
"visible" to you.
Manage internal morale and lack of "in-house ownership" issues.
Plan for knowledge transfer to maintain deliverables on an operational basis.
As this list illustrates, the outsourced project presents a litany of unique challenges, which must
be recognized and addressed to ensure successful results. As with most management decisions,
"outsourcing" viability can best be determined through a structured process for analysis and
planning.
The Outsourcing Decision
IT projects are outsourced for a variety of reasons sometimes out of choice, and sometimes,
out of necessity. When outsourcing is a matter of necessity, the reasons will usually be obvious
and clear-cut:
Lack of "in-house" time due to other projects and workload demands.
Higher "in-house" costs due to learning curves and conflicting workplace priorities.
Lack of required internal skills, resources and experience.
Political considerations (i.e. the sensitive nature of a project).
When project outsourcing is a matter of choice, the decision comes down to a balancing of costs
and benefits. This cost/benefit analysis can be summarized via the following series of defining
questions:
1. Will outsourcing help you to deliver the project on a faster timetable, and is a faster "time
to market" an imperative for this project?
2. Will outsourcing help you to deliver the project at lower costs, and is "lowest cost" a
primary goal for this project?
3. Will outsourcing help you to deliver better results (improved deliverables)?
4. Will outsourcing help you to realize short term productivity benefits?
5. Will outsourcing help you to realize long term productivity benefits?
6. What are the risks and drawbacks of outsourcing?
7. How do the risks of outsourced project delivery compare with the risks of "in-house"
project delivery?
As these questions are applied and considered in the outsourcing decision process, project
characteristics must also be examined. Certain types of projects will be more suited to
outsourcing than others. While individual circumstances will vary, the following elements can be
used as analytical benchmarks:
Expertise. What is the level of expertise required to complete the project. In-house staff
may lack the necessary skills for a high-tech projects.
Novelty. What is the level of innovation required to complete this project? In-house staff
may be needed for highly unique projects, leaving more routine projects to outsourced
providers.
Organizational Reach. How deep is the "organizational reach" of this project? Projects
having an extensive impact on internal operations may be too complex for outsourcing in
the entirety.
Dependencies: What is the level of dependency on, and connection with, other projects?
Linked projects may not be well suited to individualized outsourcing.
Outsourcing Options
Considering the issues, characteristics and internal influences, outsourcing does not have to be
an all or nothing proposition. Outsourcing can be used as an operational alternative, or it can be
used a strategic tool for project delivery. For example, you may choose to outsource an entire
project (management and all), and just maintain an "in-house" coordination responsibility. Or, you
can choose to outsource specific project elements, by deliverable or phase, based on needs,
benefits, costs and timing.
To facilitate this decision-making process, projects can be viewed as a series of operational
components:
The Vision Thing (Strategies and Tactics)
Day to Day Management (Issues Tracking and Resolution, Baselines, Resource

Management)
Planning (Scheduling, Tasks and Resource Allocation)
Deliverables Design and Development
Testing (Deliverables Verification)
Documentation (Project Documents and Technical Documents)
Administration (Logistics, Purchasing, Paperwork)
Implementation (Installation, Support and Ownership Transition)
Each of these components must be examined to determine outsourcing viability:

1. Can this component be outsourced?
2. Should this component be outsourced?
3. How will any partially outsourced components be integrated into the project as a whole?
Outsourcing for Success
Outsourcing success is not guaranteed when the initial outsourcing decision is made.
Management standards and best practices must be applied to the outsourced project with the
same degree of enthusiasm as the traditional in-house project. The following guidelines provide
you with a best practices snapshot for the outsourced project:
Make fully informed outsourcing decisions, analyzing needs, costs and benefits. see The
Outsourcing Impact Worksheet
Consider the outsourcing intangibles (employee morale and pride of ownership). see
Impact of External Consultants on Staff Morale
Clearly define all project goals, requirements and deliverables.
Choose the right outsourcing partner considering project needs, experience, and
capabilities.
Document all expectations and obligations in formal contracts and Statement of Work
documents.
Identify all likely risks and develop project contingency plans should outsourcing
problems arise.
Keep project changes to a minimum. Continual changes can wreck havoc on an

outsourced project where "requirements" are defined as part of a contractual obligation.
Schedule and hold regular status meetings with contractors and consultants. Make sure
that weekly status reports are included in all contracts and agreements. If the project
work is being done off-site, schedule regular visits to contractor locations if at all possible.
Keep in-house staff informed of all outsourcing issues that may impact internal project
work.
Be sure to conduct an in-house review of all outsourced projects to identify success

points, problems and to learn from the experience.
In summary, outsourcing is a tool for project delivery, and as with any other tool, its use must be
carefully weighed, planned and managed for success.
Related Planning Tools from ITtoolkit.com:
Post Project Reviews.....
The Project Review Survey Kit
All in one planning solution designed to collect performance feedback for projects and IT
services. The Kit contains information, advice, electronic survey forms, and pre-formatted
"Lessons Learned" templates.
Valuable lessons are hidden in every project - will you be ready to take advantage? There
is no better mechanism for performance improvement than past experience. The Project Review
Survey Kit will show you how to evaluate project performance and uncover valuable lessons
learned. Learn how to plan and conduct a review process for any type of project, taking positive
steps to identify lessons learned, correct performance problems, and strengthen future
successes.

PROJECT-SPEAK: REQUEST FOR PROPOSALS (THE RFP)

What is an RFP?
The Request for Proposal (RFP) is a specific "project procurement deliverable", used to solicit
competitive bids pending the purchase of project related goods and services. The RFP document
is a formal procurement mechanism, by which requirements are defined, questions are posed
and criteria are presented. Bidders respond to these requirements, questions and selection
criteria, providing the basis for an informed analysis of clearly defined alternatives.
Once RFP's are prepared, distributed and responded to, said responses are evaluated, and
purchasing decisions are made. As such, under the right set of project needs and circumstances,
the RFP is an essential part of the project "procurement" process.
Considering the degree to which projects vary by type and complexity, it should also come as no
surprise that RFP's vary to the same degree. First and foremost, the RFP is certainly not
applicable to every project. In general, RFP's are used when the following project conditions are
met:
Goods and/or services must be acquired from an external source.
Multiple solutions are available and alternatives must be identified, evaluated and
selected.
Product and/or service needs contain a certain degree of complexity, requiring a higher
skill level or specialized expertise.
As such, in addition to the RFP itself, there are also two distinct variations to this important
procurement deliverable, found in the Request for Information (RFI) and the Request for Quote
(RFQ). The RFI is a pre-cursor to the RFP, while the RFQ serves an alternative purpose.
Using the RFI.....
The Request for Information is a preliminary document, used to gather specific product or service
information from vendors and service providers prior to the actual RFP process. As a rule of
thumb, the RFI can be used to:
Gather additional information as required to establish valid product and/or service

requirements, particularly those of a technical nature.
Pare down the list of viable bidders prior to the actual RFP process.
Validate cost and pricing assumptions before actual RFP submission.
Using the RFQ.....

In contrast to complexities often reflected in the RFP, the RFQ (Request for Quote) is a simpler
document, used to solicit "price quotations" for products and/or services. The RFQ can be used
whenever multiple pricing bids are sought for a single defined solution (i.e. you are shopping for
the best price and terms). As such, the form and content of the RFQ will be far less detailed and
complex, and the evaluation process will be more focused on price and terms than solutions
analysis.
Using the RFP....
Considering the dependency on "requirements", the RFP process will begin at the conclusion of
the requirements phase of the project. As discussed, the RFP is a key "procurement deliverable",
to be used whenever goods or services must be purchased, and alternatives must be considered
(based on solution, source or pricing). Once the need is determined, RFP variants must be
identified (do you need an RFI, and will you issue an RFP or an RFQ?). Related Reading:
Digging Deep for Project Requirements
Why write an RFP?
The RFP is a tool within a project, and as with every other project "process", RFP production
creates an overhead factor, elongating the overall project timeline. As such, the full blown RFP
should only be utilized when needed to ensure project success.
Despite the associated time and effort, the RFP serves an important purpose within the project
"procurement" process. In a world of options and choices, the RFP is an effective decisionmaking tool, designed to ensure that the most viable solutions, and competent providers are
given due consideration.
Goals & Benefits....
The RFP process forces a defined specification of project requirements.
The RFP process provides "context" for a comparative analysis of vendors, products,
costs and services.
The RFP process promotes informed decision-making.
The RFP process provides an opportunity for vendor interaction prior to any purchasing
commitments.
The RFP process will promote successful contract negotiations, providing the basis for all
relevant contractual terms and conditions.
The RFP process establishes a standardized basis for solutions evaluation, using a
structured set of evaluation criteria.
The RFP process promotes consideration of creative solutions, opening up "possibilities"

and leveraging external expertise.
RFP Quality and Content.....

The well written RFP will be designed to convey clear, concise and sufficient information. While
form and content will vary based on procurement needs, the goal of every RFP is clear - to
ensure that every bidder has the opportunity to demonstrate how their proposed solution will best
meet your current needs. To meet this goal, your RFP must clearly lay out all requirements and
expectations in accordance with the following quality and content guidelines....
Quality Guidelines....
The RFP should be concise, precise and accurate, demonstrating that the project need is
real, and that the project team has the full authority and approval to proceed.
The RFP should be complete, providing all the information needed to ensure complete
responses.
The RFP process (response submission procedures and timelines) should be clearly
communicated.
The RFP format should be designed for clarity and ease of use.
Content Guidelines....
In order to receive the highest quality responses, every RFP should be written to convey the
following information:
Make Introductions. The RFP should provide basic introductions to the bidder
concerning the company (who is requesting the bid) and proposal scope. (providing
context for the bid).
Present the Need. The RFP should provide a brief project overview, stating the business
case for the project and the need to be filled.
State Requirements. The RFP should state the service and technical requirements and
specifications upon which the proposed solution must be based. Every requirements
statement should include a "definitions" section to ensure that all parties share a common
understanding of all business and technical needs.
Set Terms and Conditions. The RFP should state the expected terms and conditions for
solutions acceptance, including delivery requirements, payment terms, and regulatory
requirements.
Set Expectations. The RFP should describe the overall RFP bidding process, including
response submission requirements, "winning" evaluation and selection criteria, process
deadlines, and related technical procedures (response format, submission mechanisms
and how to submit questions and feedback).
In conjunction with these informational requirements, RFP bidders should be asked to respond to
the following direct questions:
How does the proposed solution (product and/or service) meet the stated requirements,
terms and conditions?
How does the proposed solution (product and/or service) exceed the stated
requirements, terms and conditions?
In what ways does the proposed solution (product and/or service) fail to meet the stated
requirements, terms and conditions?
What is the bidders track record in similar projects (as evidenced by qualifications,
capabilities, experience, and expertise)?
In addition, every RFP should ask for specific references in order to validate stated qualifications
and experience.
Conclusions....
The length and format of any RFP will vary by subject and circumstance. You may choose to use
questionnaires and/or free form text questions depending on solutions complexity, informational
needs, and available time. The most important factor in RFP formatting is consistency. A single,
standardized format will facilitate RFP response "review and analysis.
In short, the quality of every response will be directly linked to the quality of the RFP. You should
not use the RFP as a research tool, just to see "what is out there". If your RFP is not well
prepared, it will not be taken seriously by bidders, and response quality will suffer. Your RFP
should set a quality benchmark for every bidder, clearly demonstrating that your project has
value, and only the highest quality need apply.
Related Reading & Tools:
Project Procurement: Managing the RFP Process
The RFP Evaluation Worksheet
HOW TO MANAGE THE RFP PROCESS

As discussed in Project-Speak: The RFP, the Request for Proposal is an essential tool for
purchase planning and solutions analysis. As a physical "process deliverable", the well planned
and produced RFP will help you to make effective purchasing decisions, considering multiple
factors and priorities. Whenever alternative hardware, software and service solutions are
available from multiple sources, at multiple prices, and with varying terms, the RFP can be used
to compare and contrast said alternatives in a structured, comprehensive manner.
As with most other process deliverables, RFP's are best prepared through a collaborative
process, structured for a full consideration of needs and requirements.
The key elements to RFP process "success" are timing and preparation. The RFP process can
begin as soon as the foundational requirements are fully defined. (See A Process for Project
Requirements). Obviously, sound purchasing decisions cannot be made until all needs,
constraints and assumptions are known and quantified. In the event that said requirements
cannot be sufficiently quantified, the RFI (Request for Information) can be used as a fact
gathering pre-cursor to the RFP.
The RFP Process: From Planning to Selection
In order to maximize process success, RFP production should cover all of the following elements:
RFP Planning: The RFP process is planned, including the selection of the RFP Team,
identification of the chosen bidders, creation of the RFP timeline, requirements
development and creation of the response evaluation criteria.
RFP Preparation: The RFP draft is prepared.
RFP Review: The RFP draft is reviewed to ensure that all documentation requirements
are met, and comments and feedback are provided.
RFP Revision: The RFP draft is revised to reflect required changes as identified in the
"review" phase.
RFP Approval (Final): The revised RFP is approved and the final version is produced.
RFP Distribution & Support: The RFP is distributed to the selected bidders, and
support is provided as needed, including the RFP conference (if required).
RFP Response Evaluation: RFP responses are reviewed and evaluated according to
the established criteria.
RFP Selection: The RFP winner and alternative are selected, and the RFP is used to
create a contract and/or Statement of Work as needed. The losing bidders are notified to
close the RFP process.
As the process proceeds, certain decision checkpoints must be addressed:
1. Who will be involved in the RFP production process (for planning, preparation, review &
approval)?
2. Who will be involved in the RFP evaluation process (to review responses and select the
winning proposal)?
3. Will you need an RFI to further refine requirements and narrow the range of viable
options? (Tip: RFI's can be used to pare down the number of bidders).
4. How many bidders are required for optimum "alternatives analysis"? (Tip: Keep the
number of bidders as small as possible, from 3 to 5).
5. What format will be utilized (RFP or RFQ)?
6. How will RFP's be transmitted to the selected bidders (electronic or "on paper")?
7. Will you need to hold a bidders conference, or can questions be handled informally and
individually?
8. What is the expected RFP process timeline? (Tip: Make sure sufficient time is provided
for bidder response preparation, minimum 30 days. This timeframe should be built into
your overall project plan).
9. How will responses be reviewed, evaluated and scored?
RFP Scoring System:
Once RFP responses are received, each response must be reviewed and evaluated to determine
the winner. Using a "scoring system", each element of the RFP can be ranked according to the
degree to which requirements and priorities are met. This scoring system contains three
components: criteria, degree and priority.
Criteria:
Physical Requirements
To what degree does this proposal meet

stated physical solution requirements (for
hardware and/or software)?
Service Requirements

stated service requirements?
Pricing
How does the proposed price compare to the

(a) planned budget and to (b) other
proposals?
Delivery & Installation

stated delivery and/or installation
requirements?
Warranties
To what degree does the proposal meet

stated warranty requirements?
Terms & Conditions
To what degree does the proposal meet

stated contractual terms and conditions?
Skills & Abilities
Does the bidder have the necessary skills

and abilities to deliver this proposal?
References
Does the bidder have a proven track record in

this type of project?
Intangibles
What other factors can be used to evaluate

RFP responses and select the appropriate
winner?
Degree:
Using a scoring system, "points" can be assigned to each criteria component according to the
degree to which the proposed solution meets stated requirements. The following "5 point" system
provides an example:
5 points: Fully Meets
4 points: Meets, with minor gaps (no compromise required)
3 points: Meets, with moderate gaps (some compromise required)
2 points: Partially meets (significant gaps, compromise required)
1 point:
Does not meet
Priority:
The third element of the scoring system is the "priority ranking". In the course of the RFP
process, bidders will be asked to respond to multiple requirements. The degree to which each
requirement can be met will vary, even within a single proposal. On the other hand, since some
requirements will carry more weight than others, wiggle room may exist. Priority rankings will
help you to put requirements in perspective, helping you to identify the points at which
compromise is possible.
For Example: You have received several RFP responses and you have identified the solution
that best meets your technical requirements. However, this vendor is unable to meet your
delivery and installation timeframe. Can you compromise? Your priority rankings can help you
figure it out.
The following priority definitions provide an illustration:
High Priority: No Compromise Allowed
Moderate Priority: Minimal Compromise Allowed
Low Priority: Moderate Compromise Allowed
Important Note: "Compromise" will vary based on actual needs and project circumstances. In a
technical sense, compromise may be defined by your ability to forego certain functionality. In a
references sense, compromise may be defined by your willingness to take chances with an
eager, but inexperienced service provider.
Conclusions.....
Once the RFP is planned, prepared and distributed, the burden shifts briefly to the bidders to
provide relevant, targeted responses. At times, certain bidders may choose not to respond, or
may respond superficially. However, a well prepared, comprehensive RFP will usually be taken
seriously, and response quality will reflect the bidders desire and ability to meet your needs.
When the final choice must be made, a winner and alternate should be selected. The RFP
process will conclude once the winner and alternate are chosen, and all parties are notified of the
results. This notification process should include a clear statement justifying the winning selection,
and explaining the reasons why the other bidders were not selected. You never want to burn any
bridges, and respect should be shown to all parties who participated in the RFP process.
Related Reading & Tools:
The RFP Evaluation Worksheet (in PDF format)
Project-Speak: The Request for Proposal
HOW TO USE THE "STATUS QUO ANALYSIS" FOR FUNDING PROPOSALS

Every funding proposal aims for one goal ..... approval .... realized through content and effective
advocacy. Content provides substance.. and advocacy provides the reason and rationale.
As an IT professional, you may be called upon to prepare and submit a variety of
proposals .... for new hardware, upgraded software, additional staff, consultants, or to
serve any other operational need.
CONTENT AND ADVOCACY.....
Depending on the specific nature of the proposal, content begins with recommendation specifics
and detailed cost information. Advocacy is a bit more complicated, but since the intent is to
persuade, advocacy involves the anticipation of likely objections, analysis of costs, benefits and
risks, and the related examination of alternative solutions.
And any alternative solutions should include a careful consideration of the status quo.....
THE STATUS QUO ANALYSIS
In a nutshell, the "status quo alternative" addresses the impact of "doing nothing for now". But
why include "doing nothing" as an alternative, when the whole purpose of your proposal is to
enact change? By including the "status quo alternative" you can deliver realistic
recommendations and present a positive business image ... all by anticipating the concerns of
management.
When preparing your Status Quo Alternative, you will need to consider the consequences of
"taking no action for now" on several key technology and management variables. Ask yourself
the following questions....if we take no action, what will the likely impact be on......?
Our ability to upgrade or transfer technology in the future?
Our ongoing vendor relationships?
IT staff productivity, retention and professional development?
End-user productivity and our ability to provide quality support?
Our short and long term financial plans?
The need for flexibility to act in the future?
Other projects, planned or already underway?
The longevity of the "do nothing" strategy - how long can it last?
Overall company strategies for market share, expansion, reorganization or other

anticipated business change?
Technology Proposals Designed for Business

In order to ensure consideration, and to seek approval, requests for IT funding should always
stress the business side of the equation, looking at the value of the proposal and its overall
contribution to the bottom line. Try looking at the issue from a non-technical, end-user
perspective.
To that end, as you prepare funding proposals, anticipate questions and objections, and
get ready to address the following:
WHY should this investment be made?
WHAT are the short and long term costs?
WHAT is the expected return on the investment?
WHAT are the short and long term operational benefits and risks?
WHAT will the proposal cost in terms of time and human resources?
WHAT are the alternatives to be considered, including taking no action at all?
In addition, technology proposals should be considered in light of any and all realistic, probable
business benefit ...
While meaningful "status quo" analysis may take some effort, it can be time well spent.
For with just one proposal, a "status quo scenario" can effectively demonstrate that you:
Have considered all alternatives.
Understand both the technical and business ramifications of your recommendations.
Understand the need to express key technology initiatives in business terms, setting
the stage for the best possible decisions... even if that decision is to do nothing for now.
Conclusions.....
In conclusion, funding approval will depend on more than the technical quality of your proposal.
You must be able to convince management that you have carefully considered the
consequences of your recommendations, as well as all viable alternatives.
Ideas into Action:
The following tools will help you to prepare effective project proposals:
The Project Acceptance Criteria Worksheet
The Project Risk Evaluator
The Software Selection Matrix
FINE TUNE YOUR PROJECT MANAGEMENT SKILLS....

Managing Project Risks.....
The Risk Management Process Kit
Containing (5) separate components for risk management planning. You get a (55) page
Manual, filled with steps, ideas and risk management guidelines, plus (4) separate
planning forms, including The Risk Process Policy Template and The Risk Status
Template.
Prepare Statement of Work Documents.....
The SOW Process Kit contains (8) separate components for Statement of Work planning
and production. You get a (55) page Manual, filled with steps, ideas and SOW content
guidelines, plus (5) separate planning forms, including The SOW Process Plan, and (2)
templates for SOW documentation (the Quick Form and Long Form templates).
Plan Communication Strategies......
The Project Communication Process Kit
The Project Communication Process Kit contains (4) separate components for project
communications planning. You get a (65) page Manual, filled with steps, ideas and
communications planning guidelines, plus (3) separate planning forms, including The
Communications Planning Checklist and The Communication Plan Template (in Word
format).
Conduct Post-Project Reviews.....
The Project Review Survey Kit contains (7) separate components for project review
planning and lessons learned analysis. You get a (40) page Manual, filled with steps,
ideas and project review guidelines, along with (6) planning tools, including (2) fill-in
survey forms, and The Lessons Learned Template (in Word format).
SETUP A WORKING PROJECT OFFICE IN 8 EASY STEPS
What is a project office and do you need one?
The project office is a governing "resource", used to coordinate, control and support
projects for the entire organization, or within one or more internal departments. The
project office can be a physical or virtual enterprise depending upon internal needs and
capabilities.
And now for the complicated part of the question - Do you need a "project office" in your
organization or department? The answer is a likely "yes", although as always, the devil is
in the details. In fact, if you currently apply and follow standardized policies and
procedures for project management, you have already established a "project office" to
some degree. A project office can exist in varying forms, applied via customized roles
and responsibilities designed to suit project needs and circumstances.
Variations on the Project Office Theme:
Project office setups can range from "virtual oversight" to a formal operational entity.
Consider the following examples:
Type
Characteristics
Procedural
Standardized policies and procedures are established to govern

project planning, execution and management.
Oversight A project steering committee and/or auditing operation is

established to select projects, set standards and provide project
oversight.
Project management "consulting" services are provided to the
Consulting organization to support project selection, planning and
execution.
Resource
Pool
Pool of project management resources "loaned" out to various

business units to plan and complete internal projects.
Operationa Fully staffed and funded organizational entity established to

l
select, plan, execute and audit projects.
Which setup is right for you?
The form and mission of any given "project office" will depend upon individual needs
and historical project performance. A complete needs assessment is the first step, helping
you to answer one primary question - what are you trying to accomplish?
Regardless of specific form and mission, an effective project office can serve several key
goals:
Improve project performance through established standards.
Lower project costs through minimized redundancies.
Leverage specialized project management skills and expertise.
Centralize management of a multi-project portfolio.
Standardize project management services to diverse business units.
Consolidate project oversight for project performance metrics.
Maximize external vendor contracts for the delivery of outsourced project

management services.
Depending upon the goals at hand, the project office "mission" can include one or more
of the following responsibility elements:
The Project Office Mission Responsibility Elements
Set project management standards.
Manage the enterprise project

portfolio.
Review project requests and select

projects.
Act as a project resource pool.
Plan projects (from initiation to

closure).
Provide training and coaching to

project managers.
Execute and implement selected

projects.
Manage vendor contracts (for

outsourced project services).
Provide project oversight, including

audits and project reviews.
Project performance analysis and

metrics reporting.
Eight (8) Steps to Project Office Setup:

Step 1: Identify Goals and Needs
The first step in the "project office" process is to identify goals and analyze needs:
What are the primary goals for your project office?
What issues and/or problems are you trying to address?
What need are you trying to fill?
Is the project office the best way to achieve these goals and address these needs?
What type of project office structure will best suit your goals and needs?
Step 2: Assess Your Capabilities
What type of skills and staffing will be required to implement your project office?
Do you have the skills and staffing needed?
How much will it cost to setup and maintain your project office?
Do you have the available funding?
What level of management support/sponsorship will be required to successfully

plan and implement your project office?
Do you have the required management support?
Step 3: Identify Essential Stakeholders

In order to plan and implement your project office, you will need to identify the
following stakeholders:
Sponsorship: Who will sponsor (champion) your project office initiative?
Support: Who will provide internal support for your project office rollout?
Approval: Who must approve project office plans, staffing, funding and
implementation?
Planning: Who will be involved in project office planning?
Input: Who should have input into project office planning and implementation?
Step 4: Create your Plan

The project office "setup" plan should address four key issues:
What is the planned structure for your project office (procedural, oversight,
consulting, resource pool, or operational)?
What is the planned "mission" for your project office?
What is the scope of your planned project office? Note: Scope = the extent to
which project office authority will be applied within your organization or
department. For example, project office authority can be limited to projects of a
certain size, scope, cost, risk and complexity.
How will your project office be implemented within your organization? Note: You
may want to take a phased approach to "project office" rollout in order to gain
some direct exposure and experience. Best plans aside, you will learn a great deal
from actual implementation, and will have the opportunity to revise project office
specifics (mission, staffing, procedures, etc) based on real word results.
Step 5: Secure Approval

Once your project office plan has been produced, stakeholder approval should be secured
before project office implementation.
Step 6: Implement your Plan
Rollout your project office plan as developed in "Step 4" above. Depending upon your
particular setup, project office implementation can include staffing, physical premises
setup, systems setup (for project office software) procedures (best practices)
documentation and training.
Step 7: Market, Promote, Communicate
Project office success will depend upon customer cooperation and buy-in. In all
likelihood, your new (or revised) project office setup will bring changes to long
established, although outdated, operational procedures. While these changes may be
welcomed, you may also encounter resistance. An effective marketing plan will be
designed to ensure that all project office expectations, policies, and procedures are clearly
communicated, allowing for customer participation and feedback.
Step 8: Review and Revise
Any project office setup must be designed to adapt to changing business needs and
circumstances. Practical experience will provide valuable lessons learned, allowing you
to revise policies, procedures and operational standards. Once your project office is
implemented, results should be reviewed and monitored on an ongoing basis to identify
required changes, problem areas, and successful performance
HOW TO DIG DEEP FOR PROJECT REQUIREMENTS

What is a project without requirements?
a. Missed opportunity.
b. Wishful thinking
c.
Risky business
d. All of the above..

Every project should be based on a sound specification of requirements (functional, technical,
business and process). Within the project environment, requirements serve three key purposes:
Requirements form the basis for project deliverables, specifying operational

needs and functionality.
Requirements establish a consensus and common ground amongst project

stakeholders and participants.
Requirements quantify expectations into specific results, that can be given form and
substance.
Projects must be designed to deliver effective business and technical solutions. To meet that
goal, every project must also begin with an approved requirements specification. But, before
project requirements can be selected and approved, they must be collected, culled and defined.
Considering the complex nature of technology projects, requirements are typically multi-faceted
and often elusive, subject to opinion and bias. As such, the requirements collection process must
reflect these realities to identify requirements at all levels and perceptions.
Requirements Collection Methods:

Interviews: "Face to face" interviews with one or more project stakeholders. These "requirements"
interviews can occur as one-on-one meetings or group brainstorming sessions. Tip: Interviews
are most appropriate for projects with a small number of "requirements contributors", where
requirements must be gathered from a select, concentrated group.
Surveys: Documented questions (on paper or in electronic format) designed to collect "written"
requirements feedback from one or more project stakeholders. Tip: Surveys are most appropriate
for projects with a large number of "requirements contributors" where requirements must be
gathered from a diverse group.
Observation: Direct "interaction" with project customers (i.e. end-users) to observe and identify
requirements based on current workflows and practices. Tip: Observation is most appropriate for
"performance or productivity improvement" projects where problems must be translated into
actionable requirements.
In practical application, most projects will involve some combination of these various methods in
order to collect a full set of useful requirements.
Requirements Collection Techniques:
Good questions produce good answers.
Open Ended Questions: Open ended questions require more than a "yes" or "no"
response. As such, open ended questions can be used to provoke broad analysis and
discussion (to uncover opportunity and potential).
Example: What type of reports will you require from the new system?
Closed Ended Questions: Closed ended questions require only a "yes" or "no"
response. As such, closed ended questions can be used to validate previously identified
requirements assumptions.
Example: Do you require a monthly account summary report?
Hypotheticals: Hypothetical questions present a specific situation or circumstance for

which reasoned feedback is required. Hypotheticals can be used to establish
justifications and priorities.
Example: If the system produced monthly account summary reports, how would those reports be
used?
Strawman Statements: Strawman statements present specific, pre-defined

requirements "items" to be ranked in order of priority by one or more project
stakeholders. Strawman statements can be used to quickly validate requirements
assumptions, and to establish priorities amongst multiple sets of requirements.
Example: Rank the following reports in order of priority (1 - 3):

___ Daily Accounts Summary
___ Weekly Accounts Summary
___ Monthly Accounts Summary
Getting Started......
Before the requirements collection process begins, the following issues and questions must be
addressed:
Participants: Who should participate in the requirements specification process?
Requirements "contributors" should be selected according to project role, deliverables
"stake", expertise, experience, and internal organizational issues.
Timing and Scope: How much time is available for the requirements collection process
considering project scope and the number of participants? Requirements collection
"timing and scope" will determine the data collection methods to be used.
Goals What are your requirements collection goals? Do you need to validate and verify
pre-defined requirements assumptions, or do you need to gather requirements feedback at
the broadest levels possible? These goals and needs will help to determine your selected
requirements techniques, including questions "content and format"/
CONCLUSIONS:
Once requirements data has been collected, analyzed and finalized, the resulting "requirements
statement" should be verified and validated to ensure that the specified requirements match
actual needs and intent. As such, the Requirements Statement should be formally approved
before project work begins.

The Requirements Planning Worksheet (Quick Tool):
Use this worksheet to plan and document requirement collection questions and statements.
WORKBOOK PRODUCTS: New and Improved!
Project Communications...
The Project Communications Process Kit
Plan communications strategies, and manage related activities, including meetings, reporting and
more.
Project Management Standards and Best Practices....
The Project Standards Policy Kit
The right set of project management standards will help you to achieve on time, on target results
for each and every project. Learn how to plan, create and implement your own set of standards
and best practices.
Post Project Reviews and Lessons Learned Analysis....
To take advantage of the valuable lessons "hidden within", every project should conclude with a
review of deliverables, procedures and participation. This Kit provides a fast path to meaningful
post project reviews.
HOW TO DEFINE AND MANAGE PROJECT REQUIREMENTS

IT projects serve many goals ... technical, business and financial. Considering this layer of goals
and priorities, project requirements exist at many levels. As such, a solid definition of
requirements is the backbone of any IT project, paving a path for efficient project planning and
execution:
1. Requirements form the basis for project deliverables, specifying operational needs and
functionality.
2. Requirements establish a consensus and common ground amongst project
stakeholders and participants.
3. Requirements quantify expectations into specific results, that can be given form and
substance.
Within the IT project environment, requirements may vary by project type and circumstances, but
can be quantified according to four primary categories:
Functional Requirements: to determine the appearance, features and operational

functionality of the project deliverables.
Technical Requirements: to determine the technical elements of the project

deliverables, including design specifications, operational requirements, platform
compatibility, capacity and performance requirements.
Business Requirements: to determine overall project goals and vision, including

business goals, objectives, productivity expectations, return on investment and payback
requirements.
Process Requirements: to determine the project process requirements, governing the

way that the project is to be managed, including project management policies,
procedures and best practices.
THE REQUIREMENTS MANAGEMENT PROCESS:

As you go through the process of requirements identification and analysis, you need to consider
the types of requirements that must be defined, as well as the various individuals involved in the
requirements process. Since requirements define deliverables and build consensus, it essential
that all key stakeholders are involved in the requirements process as needed, whether that
involvement includes identification, review or approval.
Step One: Seek Requirements
Obtain a Requirements Statement from the appropriate project participants, in order to get a
"first-hand" perspective of project requirements from a stakeholder point of view.
Functional Requirements: provided by end-users/customers
Technical Requirements: provided by technical staff
Business Requirements: provided by end-users & management
Process Requirements: provided by IT and project staff
Step Two: Validate Requirements

Evaluate and validate requirements against business needs, technical possibilities, internal
capabilities, alternatives, and budget realities.
Are the requirements realistic?
Are the requirements attainable?
Are the requirements consistent with technology best practices, business goals, budgets
and objectives?
Are the requirements sufficient to act?
If fulfilled, will these requirements meet a viable need, or will they create new needs and
problems?
Step Three: Restate Requirements
Restate the requirements in specific terms upon which further action can be taken. This
restatement should phrase requirements in terms of the project deliverable, demonstrating to the
project customer that their requirements have been understood and that results can be produced.
Step Four: Analyze Risks
Identify the risks and assumptions upon which these requirements are based.
Step Five: Seek Acceptance & Approval
Seek acceptance and approval of your restatement of requirements. This acceptance and
approval should be obtained from all relevant project stakeholders and participants.
Step Six: Manage Change
Establish change request procedures that will allow requirements to change as the project
develops, and as needs and circumstances dictate. Requirements changes should be kept to a
minimum, and only as needed. In order to ensure that requirements changes are evaluated
appropriately, change requests should account for the following:
The individual requesting the change.
The specifics of the change.
The reason for the change.
The likely impact on the project.
Task changes required (by task, date and activities involved).
The costs involved.
Steps for review and approval.
Criteria for change request acceptance or rejection.
CONCLUSIONS.....
Considering the role that requirements play within any project, the requirements process should
be in effect from the start of the project, through closure. At the start of the project, requirements
define deliverables. As the project proceeds, requirements must remain in alignment with
changing project circumstances, and as such requirements must be controlled and managed. At
the end of a project, the quality of the requirements process must be evaluated as part of any
post project review process.
Ideas into Action:
The following quick tools will help you to plan and track project requirements.....
The Acceptance Criteria Worksheet
The Project Issues Tracking Form
The Project Progress Evaluator
The Statement of Work Process Kit:
This new version of our popular Statement of Work Template product offers more features, new
tools and added flexibility. In an easy, immediate download, you get how-to advice, (5) smart
forms for planning, review and approval, and (2) templates (one in PDF format and one in
Microsoft Word format) for actual Statement of Work document preparation. Successful
projects are the result of well defined requirements, relevant deliverables, and consistent
expectations. Get your projects started on the right track with the Statement of Work Process Kit,
and learn how an effective SOW can be a tool for project success, productivity, consensus, and
communication.
The Project Planning Roadmap NEW VERSION!
"PROJECT-SPEAK": THE PROJECT STAKEHOLDER

What is a project stakeholder? A project stakeholder can be defined as any group or individual
having a vested interest in the planning, initiation, execution or completion of chosen project
initiative. This interest can be vested in the project outcome, the project management process, or
both.
The type and degree of "interest" will vary according to the role that the individual or group plays
in the project, and the extent to which the said stakeholders are affected by project results and
consequences. As such, project stakeholders can be identified according to the following
elements:
Role
Interest
Influence
Who are your stakeholders and what is their role in the project?
Project stakeholder roles can be viewed from two perspectives: active or passive. An active
stakeholder is one who takes a direct role in the project. A passive stakeholder is one who is
indirectly involved in or affected by the project.
Active stakeholders can usually be defined by the following roles (and please note, any given
stakeholder may fill more than one role - i.e. a customer may also be a participant):
Customer or Client: The individual or group who requested the project and will benefit
from the result.
Project Participant: Any individual or group who participates in the project process.
Project Oversight: Any individual or group responsible for project management review
and authorization.
Project Advocate: Any individual or group needed to support the project effort from a
management perspective.
On the other side of the equation, passive stakeholders include any groups or individuals who
will be impacted by the project, but lack an active role in the process or result. For example, the
end-users of a new system are all "customers", but in a passive sense. As a unit, they will all
use the system, but will not be actively involved in the day-to-day execution of the project
responsible for said system. However, passive stakeholder needs must always be considered
as project plans and deliverables are defined and created. Despite the lack of direct involvement
in the project process, passive stakeholders will ultimately influence overall project success, and
if their needs are not properly considered, post project problems can result.
AVOID THIS PROJECT PITFALL: Don't rely too heavily on the
requirements set by a single customer representative (the active
stakeholder). Any failure to consider the larger needs of the entire
end-user community (the passive stakeholder) can lead to a
"requirements / deliverables" mismatch, for which the project
team will likely take the blame. Be sure to examine the big picture.
Type of interest: Anyone identified as a project stakeholder will have a vested interest in the
project, in terms of outcome (i.e. the results or deliverables), process (i.e. the way the project is
planned, managed and executed), or both. Interests should be examined carefully in order to
ensure that project strategies are properly planned and executed, and so that stakeholder
demands and perspectives can be placed in proper context. For example, a project customer will
likely be more concerned with the delivery of the end-result, than the specific mechanics of the
project process delivering that result. As a practical matter, a customer's interest will be vested
more in outcome than process. However, the interests of the project team may lie more in
process than in the result. For the team, a single project is more than just a means to an end, it is
a work environment. As a whole, stakeholder interests have to be balanced as project plans and
strategies are created.
Influence: Within any project environment, stakeholders can have a positive or negative impact
on a project. This influence may be direct or indirect, depending upon stakeholder role (passive
or active). The chart below contrasts potential influences, from a positive and negative
perspective:
Stakeholder
Customer
Participant
Oversight
Positive Influence
Negative Influence
Offers full cooperation.
Lack of cooperation.
Sets consistent requirements.
Constantly changing requirements.
Makes timely decisions.
Delays decisions.
Sets realistic priorities.
Fails to set priorities.
Performs role as expected.
Fails to perform role as expected.
Raises issues and problems

as soon as needed.
Communicates outside the chain of

command.
"Not my problem" attitude.
Demonstrates obvious disinterest.
Unwilling to hear all sides of an

issue.
Shows an interest in project

quality.
Stays informed on all project
issues.
Advocate
Passive
Stakeholder
Fails to respond to issues on a

timely basis.
Provides consistent project

support.
Fails to support the project

manager when needed.
Fails to consider all sides of an

issue.
Listens to all sides of an issue.
Shows a lack of interest in the

project.
Stays informed on the project

even without an active role.
Bad mouths project for political

motives.
Raises post-project issues

according to established
methods.
"Not invented here" attitude.
Fails to cooperate in post project

activities.
While this list is certainly not all inclusive, it does illustrate the the degrees to which individual
stakeholders can influence ultimate project success. Under certain circumstances, stakeholder
influence must be considered as a project risk. Considering political realities, some projects may
not always be warmly welcome by all concerned. And, misinformation, negative comments and
poor attitudes can quickly defeat a project, no matter how well planned the project may actually
be. As such, when stakeholders are identified and analyzed, the allies must be separated from
the adversaries, and relationship plans must be developed to deal with each in a positive way.
Uses and Applications: How can the stakeholder concept put to use within the project
planning process?
The Stakeholder Analysis: The process by which stakeholders are identified by role, and then
analyzed according to degree of interest and influence. This information is then used to plan
specific project strategies, procedures and activities throughout the project process:
Phase:
Stakeholder Analysis Usage:
Project Initiation
Identify and analyze stakeholder role, interest and influence.
Project Planning
Incorporate stakeholder analysis results into project plans and

strategies.
Project Execution &

Oversight
Maintain effective stakeholder relationships and

communication strategies.
Post Project
Transition
Request stakeholder feedback to improve future project

management practices and procedures.
During project initiation and subsequent planning, stakeholders must be identified and analyzed
according to roles, rights and responsibilities. This is an essential part of the project definition
process, helping you to put the project in proper perspective so that you can plan accordingly, set
priorities, and establish effective management procedures. The ultimate goal of the
stakeholder analysis process is to promote positive stakeholder influence and minimize
negative influence in order to ensure project success.
Specifically, the results of the stakeholder analysis process can be used in the following ways:
To create effective, realistic project definitions (assigning project priority, risk and
visibility values).
To assign targeted project roles and responsibilities (identifying skills, resources and
task assignments.
To structure an effective project organization (team organization, reporting

relationships, steering committee setup).
To create effective communication plans (information needs, communications

requirements, meeting frequency, status reporting procedures).
To identify targeted management support requirements (enlisting and ensuring

consistent and appropriate management support throughout the entire project effort).
To create practical relationship management strategies (to consider all stakeholder

needs and expectations, to ensure that all stakeholders [both passive and active] are
properly considered throughout the project process).
The Stakeholder Analysis:

As you perform the stakeholder analysis, you will need to consider the following questions:
Who are your project stakeholders?
What interest does each stakeholder have?
Is that interest active or passive?
Which stakeholders will have a positive influence on the project?
Which stakeholders will have a negative influence on the project?
What stakeholder needs and expectations exist for this project?
How will you manage these needs and expectations?
How will stakeholder needs and expectations influence communications requirements?
Ideas into Action: The Stakeholder Analysis Worksheet (Quick Tool)

WORKBOOK PRODUCTS:
more.
and best practices.
post project reviews
HOW TO APPLY SCHEDULING STRATEGIES IN IT PROJECTS

There may be no more difficult element to project planning than scheduling and estimating. But,
before you can begin to size and schedule any project, you must first determine your scheduling
strategies. Depending upon the nature of the project, and related management directives,
different approaches can be taken to project sizing and scheduling.
You will likely face one of two timing scenarios when planning a project.....
Scenario A: The Question
How long will it take you to complete this project?
Scenario B: The Demand
We need this project done by a specific date....
SCENARIO A: THE QUESTION
Approaches to Scheduling and Planning:
Forward Planning:
Forward planning is used when no specific project deadline is set, and the tasks are used to
determine the schedule, and related completion deadlines. In this case, you start at the beginning
of the project and work forward. The project timeline is determined by the total estimated duration
of all anticipated tasks. Factoring in dependencies and prerequisites, these durations are added
together to form an overall project schedule.
When you are involved in the forward planning scenario, it is a good idea to look at each task at
multiple timing levels, based on realistic planning assumptions:
Level 1: What is the shortest completion time for any given task? (assumption = everything
else goes as planned).
Level 2: What is the likely completion time for any given task? (assumption = based on
experience, some problems and changes will occur).
Level 3: What is the longest completion time for any given task? (assumption = whatever can
go wrong, will go wrong).
SCENARIO B: THE DEMAND
Approaches to Planning & Scheduling:
Backward Planning:
Backward planning is used when the completion deadline is pre-determined and the project must
be managed and scheduled to meet that deadline. In this case, planning starts with the
completion date and works backwards, analyzing and organizing tasks and events by their
individual end dates in an "if - then" fashion, until a start date is identified. For example:
Project Deadline: New server must be installed by May 1. The process ..
IF, it takes two weeks to configure the server, THEN the hardware and software must be
in hand by April 15.
IF it takes two weeks to order and receive the equipment, THEN the order must be
placed by April 1.
Whatever planning approach you use, you will need to factor the following elements into your
project timing estimate:
Task Durations: the estimated length of time that it will take to complete a task with
available resources.
Parallel Tasks: tasks that can be completed concurrently.
Predecessor Tasks: tasks that must be completed before other, dependent tasks can
begin.
Dependent Tasks: tasks that cannot begin until predecessor tasks are complete.
Slack/Float Time: slack or float exists whenever task completion can extend beyond
initial completion dates without delaying the start of subsequent tasks.
Critical Path: series of tasks that must occur as scheduled for a project to be completed
on time. There is no slack or float time along the critical path ....if any tasks on the critical
path are delayed. the project will be delayed.
Beyond Definitions: Managing Scheduling Realities

Whether you can use the forward or backward scheduling strategies, project schedules rarely fall
neatly into an orderly calendar. Problems, conflicts and unexpected events can play havoc with
the best-planned schedule. When this happens, alternative strategies have to be examined in
order to fit project requirements into available time constraints.
CONCLUSIONS.....
To that end, you may need to consider any one or more of the following questions as you look for
scheduling alternatives.
Can additional resources be added? .
Should overtime be authorized?
Should project scope be reduced? .
Should product features or quality be sacrificed? .
Are there any innovative ways to accomplish key project tasks in less time?
Can deliverables be redefined or schedules be renegotiated?
Ideas into Action:

The following quick tools can be used to plan and track the project schedule.
The WBS Building Blocks Worksheet (Quick Tool)
The Stakeholder Analysis Worksheet (Quick Tool)
The Project Progress Evaluator (Quick Tool)
WORKBOOK PRODUCTS:
more.
and best practices.
HOW TO CREATE WORK BREAKDOWN STRUCTURES

When projects are first evaluated and selected, they are largely defined by a "vision" of goals,
strategies and deliverables. But once the go-ahead is given, this vision must be quickly translated
into a series of tangible tasks and activities that can be timely executed and completed by the
project team.
Within standardized project management practices, the specification of project tasks and
activities is referred to as a Work Breakdown Structure (WBS). The WBS is an essential project
planning deliverable, serving as the very foundation of the project plan.
Depending on project needs and technical capabilities, the WBS can be produced as a simple
list, as a detailed report, or in graphical format, but the goal of any effective WBS is clear . to
translate project goals, deliverables and processes into a structured picture of tangible
work components. The WBS provides a roadmap for the project team, laying out the overall
work effort required in a logical sequence of time and responsibility.
Within any project environment, the WBS serves three primary goals:
Breaks a project down into specific, manageable work components.
Communicates tasks, schedules and responsibilities in a structured format.
Provides a baseline for progress measurement and change control.
There is no singular approach to WBS preparation, nor is there one format to follow. WBS
complexity and detail with vary based on project needs, available technical tools and the level of
experience with the type of project at hand. Regardless of complexity and format, WBS
preparation is simplified when a standardized, structured approach is taken. To facilitate the
process, you can take a "building block" approach.
This "building block" approach can be summarized as follows:
Step 1: Create your WBS building plan (through a series of planning questions).
Step 2: Select your WBS building blocks (identifiable work and structural
components).
Step 3: Arrange your building blocks into a structured framework (according to

logical workflow requirements)
Step 4: Build your WBS (format your WBS document).
Step 1: Create Your Building Plan

Your WBS building plan should begin as a sketch .... a rough outline of the work required to
complete your project. As you sit down to create this sketch, you must be prepared to answer the
following questions.....
What tasks and activities are required to achieve project results?
How much time is required the completion of each task and activity?
How will this work be structured and sequenced to ensure timely completion?
Who will be responsible for each task and activity?
Step 2: Select Your Building Blocks

Using your rough sketch as a guide, you can select the essential work components needed to
build your WBS:
Project Name: A unique identifier for your project.
Sub-Project Name: A unique identifier for a sub-set of the main project.
Phase: Logical structure for project execution, dividing a project into discrete initiatives
for better planning and control.
Task: Actual work required to produce project deliverables.
Activity: Work or events required to support project completion (i.e. meetings).
Milestone: Tasks that can be used to measure project progress.
Dependencies: Tasks that are directly linked by a dependent relationship (i.e. one
cannot begin until the other is completed).
Step 3: Arrange Your Building Blocks

Armed with your building plan and your building blocks, you must now consider your "project
perspective". The WBS presents a hierarchical view of a project. As you begin WBS preparation,
you will need to look at your project from multiple levels, starting at the highest level, digging
down to the details, and fitting in your various "building blocks" along the way.
WBS Perspectives:
Highest Level Identify the project by its name.
Middle Level Layout the project organization into a series of logical phases, allowing
the work components to be organized in a cohesive fashion.
Detailed Level Assign work components (also referred to as work packages) to each
middle level (phase).
Step 4: Build Your WBS

Specific WBS formats may vary, but an essential goal for WBS structure is usability and
perspective. As such, an effective WBS should serve a dual purpose. At a single glance, a WBS
should convey a complete image of the project structure in terms of phases and workflow. At a
more detailed level, the WBS should convey the work effort required to complete the project and
produce expected deliverables.
Highest WBS Level: Project or Sub-project Name

The Server Migration Project
Middle WBS Levels: Phases or Major Organizational Components
1.0
Requirements
2.0 Technical
Design
3.0 Pilot &

Testing
4.0
Implementation
5.0
Support
Detailed WBS Levels: The organization of tasks and activities into work packages,
identifying milestones and dependencies to form a "work package".
1.1 Task
2.1 Activity
3.1 Activity
4.1 Task
5.1 Task
1.2 Activity
2.2 Task
3.2 Task
4.2 Activity
5.2.Task
1.3 Task
2.3 Task
3.3 Activity
4.3 Task
5.3 Task
Devil in the Details:

The example noted above is an illustration of a WBS in its simplest and most straightforward
form. In ongoing applications, the level of detail and complexity will vary based on project needs.
Any given WBS could likely include work component subsets at multiple levels. For example,
tasks and activities could be further delineated into primary tasks (i.e. numbered 1.1) and subset
tasks (numbered 1.1.1, 1.1.2 and so on.....).
Considering the role of the WBS in the project environment, a certain amount of detail is a
necessity. But, it is also possible to drown a good WBS in a sea of detail. A WBS should not be
used as a "to-list". The WBS will lose its usefulness when it includes too many details. Consider
the example below:
Your goal: to quantify the work effort required to build your new file server.
Which level of detail best suits this goal?
1.1 Inventory hardware and
software.
1.1. Inventory hardware and software.

1.1.1 Open boxes.
1.2 Configure hardware.

1.1.2 Unpack hardware.
1.3 Install software
1.1.3 Unpack software.
1.1.4 Complete inventory
forms.
and so on......
CONCLUSIONS.....
As you can see, the second column reads more like a set of instructions than a specification of
the essential effort required to complete a project. An overly detailed WBS will likely create the
impression that the project is being micro-managed, a sure sign of a danger. Individual project
team members should be able to use a well defined WBS to build their own "to-do" list of detailed
tasks and activities. An effective WBS should include as much detail as needed to establish
project workflow, set time and resource boundaries, and to guide the project team to success.
Ideas into Action: The WBS Building Blocks Worksheet (Quick Tool)
Work Breakdown Structure

Summary: A good WBS is not a detailed "To do" list. But too many PMs and executives think all that microdetail gives them tight control. It actually gives them less control and a schedule that is too detailed to track and
keep up to date.
Too many project managers build a WBS that gives them no foundation for clear assignments, close
tracking or tight scope control. In the AdPM methodology we teach PMs to focus on holding team
members accountable for achievements not micro-managing them. But too many PM use the "to do"
approach.
These PMs think their work breakdown structures (WBS) should be a "To Do" list for the project so they can
tell everybody everything they need to do. As a result their projects fail most of the time. Yes, its those PMs
who are to blame for the 70% project failure rates you read about. Let's see why.
They create this big list by writing down what needs to be done in order from first to last. That approach
requires little thinking and not much time and in a short while they have a long list of to do's. When a PM
takes that approach these things happen:
The project takes about 50% longer than it should
The to do list expands weekly during the project's entire life
The project manager makes vague, unclear assignments to the team
The team spends hours in status meetings discussing what to do next
The project finishes late and requires weeks of rework after it is finished.
To avoid this nasty list, we teach project managers to decompose the project's scope into the WBS.
Decomposition takes longer than jotting down a to do list and it requires a lot more thinking. But taking that
extra time and doing that thinking gives you a professional grade WBS. Consistently successful project
managers always use decomposition because is saves time during the project and makes for better control.
Look at the section of a WBS below. It was developed using our Achievement-driven Project
Methodology. The PM took the scope and decomposed it into 7 High-level achievements (3 are shown in
the screen shot). Then the high level achievements were in turn decomposed in to smaller achievements.
Then we further divide those deliverables down to the level of individual assignments. This process takes
some thinking and you need to master the right technique but consistent success on your projects requires
that you master those skills.
Take a look at our Mentoring over the Web courses where you work with a PM mentor to master the
decomposition process by actually developing a WBS based on meetings with stakeholders.
HOW TO ASSIGN PROJECT ROLES AND RESPONSIBILITIES

It can be said that it takes a team to deliver a project.... But a team that lacks focus and direction
will have a much rougher road to success. Pave the way with a clear definition of roles and
responsibilities.
Within a project, assigned "roles and responsibilities" define the physical relationships
between the project team and the work that has to be done. Project work is most often
multi-dimensional, requiring a combination of skills and activities for planning, execution
and completion. In order to ensure that individual project tasks and deliverables are
completed as needed, it is wise to clearly define every key project activity in terms of
roles and responsibilities.
This may take a bit of effort, but there are many benefits to be realized ...
Defined roles and responsibilities create a roadmap for team participation and
involvement.
Defined roles and responsibilities set clear expectations for team members, minimizing
conflict and confusion.
Defined roles and responsibilities facilitates project management and forces structured
thinking.
Defined roles and responsibilities offers structure and consistency through project team
transitions, new team members are not simply replacing a person, they are filling a role,
and completing responsibilities.
THE RESPONSIBILITIES FRAMEWORK

To simplify the management process, providing consistency and clarity for team members, roles
and responsibilities should be organizing into meaningful categories. These categories provide a
responsibilities framework by which tasks and activities are assigned, allocated and completed
...
CATEGORY
RESPONSIBILITY
Definition
Assigned to the individual(s) responsible for the definition of a

given task or deliverable in terms of planning, specification or
design.
Execution
Assigned to the individual(s) responsible for the execution of a

given task or deliverable - seeing that the item is completed.
This is typically a leadership, or primary responsibility role.
Participation
Assigned to the team members responsible for assisting with

and participating in the execution and completion of project
tasks and deliverables.
Review
Assigned to the individual(s) responsible for the review of a

given task or deliverable for the purpose of quality control,
testing, or verification ( providing the checks and balances)
Input
Assigned to the individual(s) responsible for providing feedback

on, or information for, a given task or deliverable.
Approval
Assigned to the individual(s) responsible for approving given

project activities, requests or deliverables.
Acceptance
Assigned to the individual(s) responsible for accepting the

completion of given project tasks and deliverables, usually
involving the transfer of ownership and accountability. This can
occur when a project or a given phase is completed, or when a
task is transferred to a different project team.
IMPLEMENTING THE FRAMEWORK

Step #1: Who is on your team?
Assemble and organize the project team.
Step #2: How will the work get done?
Define key project tasks and deliverables as needed from the following perspective ...
who will define this task or deliverable?
who will execute this task or deliverable?
who will participate in the completion of this task or deliverable?
who will review this task or deliverable?
who will have input into this task or deliverable?
who will approve this task or deliverable?
who will accept this task or deliverable?
Step #3: How will responsibilities be assigned?
Allocate roles and responsibilities to each task and deliverable as per the Responsibilities
Frameworkguidelines.
Step #4: How will responsibilities be communicated?
Communicate your Responsibilities Framework to the project team as needed in

meetings and in project documentation.
Step #5: How will resource assignments be tracked and updated?
Continually review project progress and revise the Responsibilities Framework as

needed.
Ideas into Action: The Project Skills Scorecard (Quick Tool)


Valuable lessons are hidden in every project - will you be ready to take advantage? There is no
better mechanism for performance improvement than past experience. The Project Review
Survey Kit will show you how to evaluate project performance and uncover valuable lessons
learned. Learn how to plan and conduct a review process for any type of project, taking positive
steps to identify lessons learned, correct performance problems, and strengthen future
successes.
The Statement of Work Process Kit:
In an easy, immediate download, you get how-to advice, (5) smart forms for planning, review and
approval, and (2) templates (one in PDF format and one in Microsoft Word format) for actual
Statement of Work document preparation. Successful projects are the result of well defined
requirements, relevant deliverables, and consistent expectations. Get your projects started on the
right track with the Statement of Work Process Kit, and learn how an effective SOW can be a tool
for project success, productivity, consensus, and communication.
HOW TO DEFINE PROJECT MANAGEMENT RESPONSIBILITIES

To a certain extent, project management responsibilities are largely the same whether you are
managing a technology project or some other type of project. In a standard sense, all project
managers are expected to create a workable plan and manage it to a successful conclusion. But,
obviously, the details vary, and in the IT environment, many non-traditional project factors come
into play.
To begin with, IT projects can vary greatly in size, substance and complexity, ranging from
application development projects, to end-user training initiatives. In addition, many IT
"project managers" are first and foremost, technology professionals who find themselves
in the position of managing projects. And, these projects are just another line item on a
long to-do list that can include systems administration, end-user support and problem
management. As such, the IT project manager may not be dedicated to a single project as
in an otherwise traditional project management role.
Considering these issues, how can IT project management roles and responsibilities be identified
and assigned to ensure project success and workload balancing?
Step 1: Understand project needs.
Step 2: Acknowledge staff capabilities.
Step 3: Align needs & capabilities with responsibilities.
Step 1: Understand project needs

In order to develop and define project management responsibilities designed to suit the needs of
any given project, you must first have a good grasp on those needs. This understanding must go
beyond the specific technical elements of the project, and into the core issue of project
management .... what will it take to drive the project to success? To that end, as you define
project management responsibilities, and in turn, look to find the right person to fit this project
management role, you should consider the following questions....
Is there a customer?
Strange as it may seem, not every IT project will have a specific customer. Ultimately,
the business itself is the ultimate IT project customer, but for certain technology projects,
such as server or infrastructure upgrades, there may be no specific end-user group
involved. In these projects, end-user communications and relationship management
skills may take a back seat to pure technical and time management skills, and therefore,
project assignments can be made accordingly.
Are external consultants or vendors involved?

In this case, the internal IT project manager may need to fill a liaison role, and
communications and organizational responsibilities will become a primary factor in project
success.
What is the IT role?

Considering the extent to which technology is now used in business, the IT organization
is often called upon to play a role in non-technology projects ... those which rely on
technology for the results, but do not focus on technology itself as the result. In these
cases, IT usually plays a support role in the overall project, but the technology elements
become a sub-project of the whole. This can mandate a dual role for the IT project
manager .... to manage the sub-project, and play a secondary, support role in the primary
project. This can be the most challenging IT project assignment of all.
Step 2: Acknowledge staff capabilities

As project management roles and responsibilities are assigned, internal capabilities must be
considered to ensure that roles and responsibilities are realistic and that the desired results can
actually be achieved. When determining project management responsibilities, the following issues
must be considered....
Skill levels .... does any one individual have the necessary skills to carry off the project.
If not, can project management responsibilities be shared or allocated?
Available time .... considering other priorities and existing workload, can any one
individual devote sufficient time to the project? If not can the project scope be modified,
or broken down into sub-projects assigned to different individuals?
Available funding .... do you have sufficient funding to outsource management of this
project if skills and time are lacking?
Priorities .... can other projects or workload be balanced differently to allow for one
individual to manage the project at hand?
Authority ... how much authority will the project manager need to get the job done, and
is that level of authority organizationally feasible? If not, what are the risks associated
with a lack of authority and how can management responsibilities be assigned to
compensate?
Step 3: Align project needs and staff capabilities with project

management responsibilities
Considering project needs and internal staff capabilities, you will then need to identify the project
management responsibilities required to drive the project to success.
Technical Responsibilities:
Does the project manager have to have specific technical skills or expertise to manage this
project?
Planning Responsibilities:
What planning responsibilities will be required to manage this project?
Identify technical requirements.
Define scope, goals, and deliverables.
Identify resource requirements.
Select the project team.
Estimate time, costs and schedules.
Prepare and present the project plan.
Execution Responsibilities:
What execution responsibilities will be required to manage this project?
Hands-on technical contributions.
Maintain and monitor the project plan.
Approve, reject and apply change requests.
Monitor and resolve open issues.
Track project progress.
Manage the project budget.
Manage vendor and supply relationships.
Communications Responsibilities:
Communications with the Project Customer (End-User):
Does this project have a specific customer?
What types of communications will be required?
Interviews to obtain requirements.
Negotiation of requirements, acceptance criteria, schedules and scope changes.
Problems and issues communication.
Status reporting.
Communications with the Project Sponsor / Management:
What types of communications will be required?
Negotiations for resources (staff and funding)
Status reporting.
Problem escalation.
Coordination with a project steering committee.
Staff Responsibilities:
What staff management responsibilities will be required?
How large is the project team?
Depending on the size and experience of the project team, what extent of staff
management experience is required?
Will all team members report directly to the project manager or to project team leaders?
Will project team members continue to report directly to line managers during the term of
the project?
Will the project manager be responsible for evaluating staff performance?
Will the project manager have the authority to remove or reassign project team
members?
Management Expertise:
Depending on the size, complexity and visibility of the project, should the project manager have
extensive management experience, or can an inexperienced manager be assigned?
CONCLUSIONS.....
Within the IT environment, "project manager" may very well be a function more so than a title. As
such, there is no one way to fill the project managers role. Project management responsibilities
need to cover the basics in planning, execution and communication, but must also account for the
variations in project requirements, and multi-dimensional facets of the IT operation itself. When
assigning project management responsibilities, these factors must be considered to ensure that
all projects can be completed, while overall IT objectives are met.
WORKBOOK PRODUCTS:
more.
and best practices.
THE ROLE OF THE END-USER IN IT PROJECTS

What role do end-users fill in IT projects?
Are they managers, customers, partners, bystanders or some combination thereof? As can be
expected, there is just one answer "it depends". End-users can fill any number of roles within a
project depending upon project type, organizational structures, and the quality of the relationship
existing between the end-user community and the IT project organization.
There is only one certainty the quality of the relationship between IT and the end-user
community is essential to success for most IT projects. Unfortunately, the IT/end-user
relationship is not always smooth and productive. In fact, under certain circumstances,
these relationships can turn adversarial. This may very well be the "nature of the beast",
as natural territorial and political concerns rise to the surface. IT staff may feel that their
accountability is an automatic entitlement to project control and ownership. On the other

side of the equation, end-users may feel they should drive the project process, as they
hold the long term interest in final project results. This sets up a natural conflict that must
be overcome if projects are to proceed smoothly, delivering the required results.
As such, the management of the end-user relationship within the project environment is the
responsibility of the project manager.
The Project Blame Game:
The project blame game has two players and two perspectives. The game begins as a battle over
technology project control. Team "IT" believes that end-users should not control technology
projects because they dont understand the technology, dont have a handle on their own
requirements and they change their minds too often. Team "end-user" believes that they should
have control over technology projects because IT places too much emphasis on technical needs,
and not enough on business needs, is largely inflexible, and is either unwilling or unable to accept
or understand end-user requirements. And so the game begins..
Avoiding the Project Blame Game:
In order to deliver successful projects, the IT project manager must face the "blame game"
possibilities, taking steps to overcome the conflicts. Ultimately, the primary goal is the avoid the
game, and to create one project team with the same set of goals and objectives.
Step One: Understand Project Requirement and Organizational Needs
Ultimately, the needs of the project should determine the role and extent of end-user involvement.
Some projects should be managed by the IT organization, and other projects are better managed
by the end-user community. The deciding factor may very well be the extent to which technology
is the "deliverable" or an "element" of the project outcome. For example, end-users may be better
suited to manage a relocation project, where technology is but one factor in the project result
i.e. to change office locations. On the other hand, a project to roll-out a new e-mail system may
be better served by management run out of the IT operation. Again, it will all depend on your
organizational needs and attitudes. If the goal is to manage successful projects, then project
management responsibilities should rest with the organization best able to deliver successful
results by virtue of skills, available resources, time and capabilities.
Step Two: Consider the Possibilities
As discussed, end-user involvement will probably vary by the nature of the project at hand, but
can encompass any of these possibilities:
End-User Project Management: End-users will assume project management

responsibility, and IT staff will act as a project team members. In the alternative, and if
appropriate, IT can run its own sub-project focusing on the technical elements of the main
project, to be later integrated into the whole.
End-User Team Assignments: One or more members of the end-user community will
take on assigned responsibilities as active members of the project team, reporting to the
IT project manager.
End-User Project Liaisons: End-user staff can assume a coordination role within the
project, acting as a middleman between IT and the end-user community on project
related issues.
End-users should never be eliminated from projects in entirety, even if the project is purely
technical (i.e. to swap server hardware over a weekend). While end-users may not have any
specific input into this type of project, they have a vested interest in the outcome, and should
always be considered and consulted.
Step Three: Identify Roles and Responsibilities
In order to build effective relationships, end-user roles and responsibilities should be clearly
defined. Obviously, if end-users are to manage a given project, they will the ones to define "IT"
roles and responsibilities, so these guidelines are meant to address those circumstances where
project management ownership rests with IT. In this circumstance, end-user roles and
responsibilities should be clearly defined and documented:
Essential End-User Roles & Responsibilities:
Define business needs and requirements.
Work with IT to specify deliverables.
Work with IT to specify acceptance and success criteria.
Follow established change control procedures to minimize unwarranted change requests.
Establish communications channels to report issues and change requests.
Participate in demonstrations and tests as needed.
Provide feedback as needed after tests and pilots.
Work through problems and issues without blame and finger-pointing.
Step Four: Communicate

Effective communication will be a key factor of success in avoiding the project blame game. As
you work with your end-users to define project involvement, you will need to use all your
communications skills in order to....
Understand and acknowledge end-user concerns.
Negotiate roles and responsibilities.
Market IT project skills and capabilities, focusing on prior success stories, or, if needed,
on lessons learned from prior experiences
Help end-users to define their needs.
Communicate roles and responsibilities through documentation and in meetings.
Step Five: Monitor the Relationship

As your project progresses, you need continually monitor the IT / end-user relationship for signs
of the "blame game". As a pragmatic project manager, you need be on the look out for any
signals indicating potential relationship break-downs:
Disgruntled project team members.
Any sudden changes in team attitude or work dynamic.
An increase in management complaints and reported problems
Frequent change requests.
Unexpected project delays.
Negative attitudes and internal team conflicts
If these signs are apparent, you need to take quick action, including head-on, open discussions in
group settings or in one-on-one meetings. Confront problems, find causes, and take action to
resolve through negotiation, procedural changes, increased communication, or any other valid
means available. Once problems fester, they become harder to resolve and address.
Step Six: Transfer Project Responsibility
Once a project is completed, formal ownership should be transferred to the appropriate
organizational entity. Projects should close with a formal meeting to transition results, review the
project and acknowledge participation. These efforts can generate positive feelings that may very
well linger on into the next project.
CONCLUSIONS.....
At the end of the day, projects rarely succeed or fail on technical factors alone. However, poor
relationships, power struggles, and a lack of cooperation and teamwork can doom a project from
the very start. Since IT projects depend upon the quality of the IT/end-user partnership, it is wise
to treat end-user involvement as an essential element of the project process, and to organize
accordingly, even if it means some loss of "control". The ultimate goal of any project is the
successful delivery of required results. Any steps taken to increase the odds of success will
benefit all concerned.
Ideas into Action: The Stakeholder Analysis Worksheet (Quick Tools)
WORKBOOK PRODUCTS:
Project Communications... The Project Communications Process Kit
more.
and best practices.
Post Project Reviews and Lessons Learned Analysis.... The Project Review Survey Kit
HOW TO CREATE PROJECT JOB PROFILES

Every project is a "mini-enterprise", which must be organized and staffed according to specific
needs and planned deliverables. Every project manager faces the same questions when
planning a project....
What types of skills and tasks are required to complete this project?
How will roles and responsibilities be allocated to complete the project on time, as
needed, and on budget?
How will the project team be organized into discrete "job functions" and reporting
relationships?
These questions and related conclusions are key to the success of any project. So, any tool used
to simplify or streamline the project "staffing" process will be a welcome resource. Enter the
project job profile. (PJP).
Project job profiles differ from the traditional job description because of the varied approaches to
project staffing, as the following list demonstrates:
Projects can be staffed through a dedicated project management organization (i.e.

project office).
Projects can be staffed "temporarily" by individuals with other (non-project) job titles,
assigned to projects on an as-needed basis. These individuals may continue to fill their
operational roles while they work on projects.
Projects are staffed by outside contractors and/or consultants (in whole or part).
Projects are staffed by some combination of the three variables listed above.
Considering these organizational variations, project job profiles can be used in a variety of ways:
1. To staff permanent project management positions. (profiles with an organizational
perspective). Organizational profiles are synonymous with the traditional job description
because they represent permanent functional positions.
2. To specify titles, roles and responsibilities for "as-needed" project work, or to retain
contractors/consultants (profiles with a project perspective). In this case, project job
titles are unique to the project at hand, and do not replace official, functional job titles.
(Example: A Help Desk Manager is assigned to work as a Project Manager for a software
training project).
At a minimum, the PJP should be used as a standardized planning tool, to streamline project
staffing, to minimize redundancies, and to promote official recognition for the project
"participant". Whether PJP's are used from an organizational or project perspective, these
profiles should be created with "productivity" in mind. To minimize redundancies, generic

profiles can be created for common project related jobs (every project needs a manager, every
team needs a leader). Targeted profiles can then be created to account for unique job
requirements created by specific types of projects.
Generic Profiles: Project Director,
Project Manager, Team Leader,
Administrator, Auditor, Finance
Manager, Procurement Manager.
Targeted Profiles: Usability Tester, Change

Management Supervisor, Project Specialists:
Technical Design, Programming, Software,
Administrative, Technical Writers, Security.
These generic and targeted PJD's form a "job profile pool", which can then be matched to the
available resource pool to form team structures, and assign roles and responsibilities.
Job Profiles and The Project Process .....
The "job profile" deliverable comes into play as part of the project initiation phase, when projects
are first defined and structured. The project manager reaches into the pool of standardized PJP's
to identify project "job" requirements, customizing each as needed to create targeted job profiles
for assigned staff. Resources can then be assigned to each "position" as needed to completed
the project as planned.
The key to PJP preparation is brevity and precision. Effective PJP's will be designed to clearly
communicate duties, responsibilities and expectations, touching on most, if not all, of the
following elements:
Job Title: To provide a descriptive name for the project position.
Tip: Project team members should be given titles that reflect primary project function i.e.
Documentation Specialist, Risk Assessment Specialist, Purchasing Coordinator. In addition, job
titles should also be designed to reflect experience, i.e. Senior Project Manager vs. Project
Manager.
Purpose: To provide a brief overview of the position "objectives" and primary role within the
current project or project organization.
Duties & Responsibilities: To list the tasks, activities, decisions and related work obligations
associated with this job position. Note: If the position holds supervisory authority, certain "duties
and responsibilities" will likely be delegated to others, but accountability remains.
Primary Deliverables: To list the key, measurable deliverables (results, outcomes) for which this
position will be responsible and accountable.
Skills: To list the technical, management and professional skills needed to perform the requisite
duties and tasks.
Examples: (a) Project Skills: Project definition, planning, documentation, scheduling, budgeting,
risk planning, issues tracking and progress measurement. (b) Supervisory Skills:
Management, delegation, motivation, performance evaluation. (c) Technical Skills:
Programming, design, testing, installation, technical support, problem resolution. (d) Soft Skills:
leadership, communication, negotiation, time management, conflict resolution, creativity.
Level of Authority: To define the authority held by this position. Within the project environment,
authority can exist at multiple levels:
Supervisory Authority (over other staff members).
Decision Making Authority (relating to strategies, tactics, issues, priorities and problem
resolutions).
Financial Authority (expenditures, purchases, contracts, budgets).
Approval Authority (to accept requirements, specifications and related deliverables).
Level of Autonomy: The degree to which the position is self-directed.

Reporting Relationships: The relative positioning of the "job" within the organizational hierarchy
of the project. Who does this position report to, and how many direct, and indirect reports will this
position manage?
Logistics: To define physical and logistical work parameters including location, travel
requirements, assignment length, and expected time commitment (full or part time assignment).
Preparing the PJP:
The first step in preparing a catalog of standardized "project job profiles" is to look back at
completed projects to find commonalities:
What types of "jobs" have been typically required in past projects?
How have project teams been organized?
How were roles and responsibilities defined and allocated?
What "lessons learned" can be applied to create pro-forma job profiles for future
projects?
Once the PJP Catalog is created, project managers can then use the catalog as a reference
point to identify resource requirements, organize the project team, and assign roles and
responsibilities. In order to ensure that this PJP Catalog can be used effectively, all included
profiles should be written using a standardized format, (See: Project Job Profile Template),
relying on "action verbs" whenever possible to describe duties, responsibilities and expectations.
(Action verb examples: define, create, prepare, produce, determine, approve, analyze, evaluate,
plan, coordinate, organize, schedule, lead, implement, install, supervise, decide, establish,
monitor, track, report).
CONCLUSIONS......
In short, effective project job profiles will be brief, precise, relevant, and easily customizable.
And, even if they are used solely in the virtual sense (for internal planning only), and not to
advertise available positions (internally or externally), these profiles will provide many important
benefits and advantages:
To standardize project titles, roles and responsibilities.
To add credibility within and for the project team.
To streamline the resource planning process.
To save time and minimize redundancies.
Related Tools and Reading:
Project Job Profile Template (Quick Tool in PDF format)
Project Resource Management Glossary (Deliverables, Process & Concepts)
WORKBOOK PRODUCTS:
more.
and best practices.
CONTROL ROGUE PROJECTS IN FOUR STEPS

Are you taking the blame for rogue technology projects?
It is an all too common occurrence. End-users go around IT to select, fund, plan and execute
their own technology projects. And, when problems arise, IT gets the blame, even though the IT
organization had no part in the project itself. And, adding insult to injury, IT may find itself stuck
in the middle of a major political dispute (caught between management expectations and enduser frustrations). What's an overworked IT manager to do?
Rogue technology projects are typically conceived and executed outside established IT
management channels. By definition, these rogue projects can be organizationally selfdefeating. Centralized IT project operations are established for a reason .... to control
project selection and promote global technology strategies, maximizing technical
compatibility, minimizing redundancies, leveraging specialized skills, lowering costs, and
(hopefully) improving results.
The risk for rogue projects to occur rises with the degree of organizational centralization:
Fully Centralized = Highest Degree of Risk. Since all projects are to be centralized,
any rogue project represents an process failure and an organizational problem.
Partially Centralized = Moderate Risk. In a partially centralized environment, only

certain types of projects will be subjected to centralized management and oversight.
These projects usually share common characteristics (size, scope, cost, risk). In the
partially centralized environment, the risk is that the "wrong" type of project will be
undertaken outside the control of the established IT organization.
Decentralized = No Risk. Once the decentralized model is established, the risks of

"rogue" projects have already been accepted. Note: This does not mean that a
decentralized project approach is without risk, it means that, in a given situation, the
benefits of decentralization (flexibility, quick turn around) outweigh the risks (see the "risk
list" below).
Specifying the risks of rogue projects....

1. Rogue projects can increase the overall number of projects undertaken and executed.
This causes costs to go up and increases overall project risks.
2. Rogue projects cannot be managed as a "project portfolio" and as such, they can be
redundant, and more difficult to track for value, return on investment and lessons learned,
3. Rogue projects may not be completed according to standardized project management
and/or technology "best practices", leading to higher costs, greater risks and lost
productivity.
4. Rogue projects can produce incompatible deliverables, leading to conflicts and issues
with technical interoperability, scalability, capacity, integration and security.
5. Rogue projects may not be properly aligned with strategic IT objectives.
6. Rogue projects may increase "total cost of ownership" for resulting technology
deliverables, increasing support costs and complicating support requirements.
7. Once completed, rogue projects might have to be re-done to conform to technical or
organizational standards, increasing costs and wasting resources.
In order to cope with, and potentially take control of rogue projects, you must be able to assess
the cause, effects, and scope of the problem. Once this assessment is complete, you must then
develop workable approaches and take corrective action.
Step 1: Assess the Scope
Do you have a "rogue project" problem? To identify the nature and scope of any such problem,
you must consider the frequency and impact of any and all "rogue projects" with a series of
defining questions:
How many rogue projects have been initiated in your organization?
Of the total number of rogue projects, how many have been completed?
Of the total number of completed rogue projects, how many can be considered
successes or failures?
Of the total number of rogue projects, how many were abandoned?
What are the costs associated with these various categories of rogue projects (completed
and successful, completed and failures, and/or abandoned)?
Are there any common characteristics to be found amongst these rogue projects
according to the aforementioned categories?
Of the total number of rogue projects, how many had to be re-done, and what were the
total associated costs?
Note: The purpose of this assessment process is twofold. First, you need to get a handle on the
"rogue project" problem in terms of numbers and consequences. In addition, the scope
assessment process will likely provide vital information about the historical "result" of rogue
projects, helping you to identify the "type" of projects that might be best suited to decentralized
management.
Step 2: Find the Cause
Why do your end-users choose to work around IT to plan and execute their own projects? There
can be several reasons:
Service Dissatisfaction: End-users work around IT because they are generally

dissatisfied with the project services provided. Dissatisfaction can be caused by any
number of factors, including poor quality, lack of communication, failure to complete
projects on time, project backlog, failed deliverables, etc. See Project-Speak: Lessons
Learned.
Bureaucracy Avoidance: End-users work around IT to avoid the so-called bureaucratic

"overhead" associated with IT sponsored projects. Bureaucratic overhead might include
forms, approvals and oversight requirements. In addition, end-users might not want to
"wait in line" to have their projects completed.
Corporate Culture: End-users work around IT as a part of the prevailing corporate

culture, such as an inherent resistance to external control, or the desire to "just do it
yourself".
Poor Communication: End-users work around IT because they are generally unaware
of project procedures, and do not understand the benefits of the centralized project
approach.
Lack of Management Support: End-users work around IT because company

management does not promote or support centralized technology projects. In fact,
company management may even promote "rogue projects" through a "just get it done, I
don't care how" attitude, or through an apparent disinterest in technology projects.
Step 3: Develop a "Rogue Project" Management Strategy

Once you gain a solid grasp on both the scope and underlying cause of your "rogue project
problem", you will be better positioned to engage workable management strategies. These
strategies can encompass total elimination (which may be impossible) to total acceptance
(which may be unwise). In all likelihood, the most workable solutions will lie somewhere in the
middle. To eliminate rogue projects in entirety, you must be able to rely on the following factors:
You must have strong, tangible and visible management support.
You must have the authority and capability to enforce the ban on rogue projects.
You must have sufficient resources (staffing, funding, and time) to deliver on an
expanding project workload.
If these variables cannot be met, then a more practical approach is warranted. The key to this
approach is mitigation - to minimize the negative impact of rogue projects through coordination,
communication and procedural standards:
Set organizational standards to guide all technology related projects, to be applied

whether projects are completed by the IT organization or individual business units.
Set project thresholds, allowing smaller, less strategic, less costly projects be completed
in a de-centralized fashion, while larger, riskier and more strategic projects will be
completed (or at least supervised) by the centralized IT organization. Tip: Use the
results of "Step 1: Assess the Scope" to set your thresholds. This scope
assessment will likely reveal the types of projects that have been successful under
decentralized management.
Offer a menu of services for project support, allowing end-users to work with IT in a
cooperative fashion to select, plan and execute technology projects.
Include end-users in all strategic planning efforts, to ensure that all issues (and
objections) are considered, to build consensus, and to build essential buy-in.
Get management approval for any "rogue project" strategy before activation.
Management support is essential to success. Without it, you may lack sufficient authority
to implement related policies and procedures. In addition, all potential project
stakeholders need to know that they have a vested interest in "rogue project" mitigation,
to minimize risks and maximize benefits.
Identify the consequences associated with continued "rogue projects". Rogue projects
may not cost someone their job, but they certainly should have consequences. Before
mitigating strategies are implemented, related consequences must be identified. For
example, management may decide that rogue technology will not be maintained or
supported by the established IT support organization.
Step 4: Take Action
Communicate. Once strategy development is complete, the results must be

communicated to all concerning in a clear and tangible manner. End-users must be
made fully aware of all applicable policies and procedures for the selection, planning and
execution of technology related projects. These communication efforts must be designed
to inform, convince, and solicit feedback.
Be Consistent. Whatever your "rogue project" strategy may be, you should be
consistent in its application. While flexibility is essential, consistent enforcement will build
credibility and provide a basis for performance analysis.
Review Results. Once your "rogue project" strategies are implemented, you must
continually review results to determine if and when changes must be implemented. This
review should consider multiple issues based on overall goals and objectives....
o
Have the number of rogue projects decreased? If not, why, and how can the
number of rogue projects be further reduced?
Are you getting better project results? If not, why, and how can policies and
procedures be further improved?
Have you had sufficient management support for your "rogue project"
strategies? If not, why, and how can management support be improved?
Have you been able to maintain the quality of your IT project services? If not,
why, and how can service quality be improved?
Conclusions....
In a busy, fast paced business environment, you probably won't be able to gain control over every
technology related project. Ultimately, the goal is to achieve the best possible result - through
standardized best practices, tempered with flexibility, cooperation, reason, shared responsibility,
and authority. Wholly centralized project control only makes sense to the point where these goals
can be realized and maximized.
Related Reading:
The Role of the End-User in IT Projects
Graceful Exits from Troubled Projects
Project-Speak: The Project Stakeholder
Ideas into Action: Project Services Request Form
One of the most practical and effective approaches to "rogue project" mitigation is to make it
easier for end-users to identify project needs and request project services. This latest entry in our
Quick Tools series will help you to achieve that goal. This form is designed to collect project
information and to request project services from pre-defined categories. Using this form, project
customers will be asked to describe the project, state their business case, and request specific
project related services. Use of this form will help you to organize, evaluate and prioritize project
requests, forming the basis for services planning and project delivery.
THE PROJECT STANDARDS POLICY KIT
Project success should not be hit or miss. We all know that projects have to be managed - the
question is how? With the right set of standards, your projects will be managed the way you
want, with consistency and quality. The Project Standards Policy Kit, from ITtoolkit.com, gives
you all the tools and information you need to create and implement your own customized set of
"how-to project standards", covering project initiation, planning, execution, control and closure.
Develop your own customized set of project management standards and best practices
(for project initiation, planning, execution, control and closure).
Document these standards using the pre-formatted Standards Policy Template, provided
in Microsoft Word format.
Plan, produce and maintain your standards policy following an easy, step by step
process, covering policy planning, document preparation, review, approval, version
control and ongoing maintenance
The Project Standards Policy Kit is available for immediate download, containing The
Policy Kit Manual (PDF) and The Project Standards Policy Template (Word).
HOW TO ESTIMATE AND TRACK PROJECT COSTS
The management of project costs can be the most complicated, political, (and tedious) element of
the project management process. But, costs have to be controlled, for the sake of IT credibility,
and the overall fate of current and future projects.
THREE STEPS TO PROJECT COST MANAGEMENT
To identify project cost factors.
To estimate cost values and create a budget.
To track costs and monitor variances.
Step #1 Identifying Cost Factors:

While cost factors will vary based on project characteristics and business circumstances, in
general, project costs can be viewed from four basic perspectives:
Resource Costs: the costs involved in staffing a project, which can include:
Salary
Benefits
Outsourcing Contracts
Temporary Staffing
Overtime
Asset Costs: the costs of asset acquisition, usually involving tangible assets that are used to
create or implement project deliverables, which can include:
Hardware
Software
Peripherals
Infrastructure
Telecommunications Equipment
Installation Tools
Overhead Costs: the costs involved in maintaining the project environment, enabling project
completion, which can include:
Office Supplies
Premises (rent, utilities)
Support Services
Project Specific Costs: costs of project execution, consumed in the completion of the project,
which can include:
Travel
Meals
Meeting Costs
Print Production & Photocopying
Step #2 Cost Estimates and Budgets:

Project budgets quantify the expected costs associated with a project, and these budgets must be
based on a reasonable, realistic estimate of likely project costs and expenses. The estimation of
project costs is part science, and part logic, common sense and experience.
In fact, past projects can be the most valuable indicator of current project expenses. As project
costs are estimated, the following factors should be considered:
The specific cost factors involved depending on the needs of the project.
The costs of similar projects in the past.
The opinions and feedback of project participants. When estimating costs, it is important
to get a broad spectrum of information, experience and opinion.
As you estimate costs, different tactics and formulas can be applied:

Resource Costs
Calculated on the basis of ...
Staff hours x hourly rate (factoring salary and benefits)
Temporary staff hours x hourly rate
Outsourced contract fees
Overtime hours x overtime rate
Asset Costs
Calculate on the basis of actual costs of tangible assets.
Overhead Costs
Normally expressed as a percentage of resource costs.
Project Specific Costs
Calculate on the basis of actual expenses.
Since project cost estimates are just that .... estimates ...., it is unlikely that related project budget,
resulting from these estimates, can be etched in stone. Projects have a pulse, and the
circumstances and conditions under which projects occur can, and do change, impacting costs
and expenses. To deal with this uncertainty, project managers often apply a "contingency factor"
when preparing a project budget. This contingency factor normally consists of a 5 - 10% boost of
anticipated project expenses in order to uncover inexperience, as well as the "unknown" or the
"unexpected".
Depending on the degree of internal experience with a given type of project, contingency
reserves may or may not be necessary. In addition, there is a philosophy that says that
contingency reserves are dangerous, leading to unwarranted project spending.
CONTINGENCY PRO'S
CONTINGENCY CON'S
The extra funds are in hand when needed,

without seeking further approval.
Contingency reserves make it easier to gloss over

project costs, making budgets less precise.
Considering that project circumstances can
Contingency reserves encourage cost overruns, by
change so frequently, contingencies readily

acknowledge this fact, facilitating project
completion.
granting easy access to additional funding without

a thorough consideration of alternatives..
Considering the duality of the contingency reserve issue, the prudent course of action may be the
creation of a contingency/change control budget, which can be tapped only when specific
circumstances are met. In this fashion, project estimates are left whole, without any "fudge"
factor, but contingencies are sufficiently addressed in order to facilitate project execution and
completion.
Step #3 Tracking Costs and Cost Variances:
Once the project budget is created and approved, and the project is underway, costs and
expenses must be tracked to ensure that budget utilization matches project progress (are you
spending what you expected to spend based on how the project is proceeding?).
Budget variances can be tracked on a monthly basis, for a targeted project picture, as well as on
the basis of the project as a whole, for a global perspective.
Monthly
Variance:
Monthly Budgeted Expenses - Actual Expenses = Variance Amount

Variance Amount
Monthly Budget
Project
Variance:
x 100 = Variance Percentage
Project Budgeted Expenses - Actual Expenses = Variance Amount

Variance Amount
Project Budget
x 100 = Variance Percentage
Once you identify any budget variances, you can look to the explanations .... is the variance
positive or negative, and what does it all mean?
A positive variance: indicates that you are under budget, but appearances to the contrary not
withstanding, this is not necessarily a good thing. When project expenses are less than expected,
this may be a sign that the project is not proceeding according to plan, and may be behind
schedule. In addition, a positive variance may be a sign of ineffective estimating. On the other
hand, this under budget condition may be the result of legitimate changes, discounts, or cost
saving measures.
A negative variance: indicates that the project is over budget. Depending upon whether the
negative variance is at a monthly or overall project level, this variance may be the result of
serious project problems, such as excessive changes, schedule delays or ineffective budgeting.
If the negative variance is on a monthly level, but the overall project is on track, there may not be
an immediate cause for concern.
CONCLUSIONS.....
As you can see, project estimating and budget control is more than a process of numbers. As the
project budget is tracked, the results of the tracking process can be used to monitor project
success, and to highlight potential problem areas for further analysis and possible corrective
action.
Ideas into Action:
The Project Spending Report: Use this quick tool to track and document project "spending
status" for specific periods of time.
WORKBOOK PRODUCTS:
more.
and best practices.
RESOURCE MANAGEMENT GLOSSARY: Deliverables, Process & Concepts

About the Glossary: This project resource glossary provides definitions for the key terms,
words and concepts involved in "project resource management". The glossary is
structured for practical reference, organizing these elements according to purpose and
function:
If the term is the tangible result of resource planning, it is a deliverable.
If the term relates to resource planning "execution", it is a process.
If the term is a theory, method or issue in resource planning, it is a

concept.
Primary Definition: A project resource can be defined as any person, tool, equipment,
material or service used to plan, manage, monitor and complete a given project. Resource
management is the primary process by which "project resources" are assigned and
utilized.
Part One: Deliverables
Resource Plan: Documents and defines the resources required to plan, manage
and complete a given project (or portfolio of projects). Resource Plans can be
prepared to cover all "resource" elements (people, materials, and equipment). The
"Staffing Plan" is a sub-set plan, specifically relating to the use of "human"
resources within a project.
Resource Breakdown Structure (RBS): Hierarchical structure of project

resources organized by function, allowing for detailed organizational views, with
a roll-up to higher levels. Similar to an organizational chart. Purpose: to document
the project "organization" at multiple levels.
Responsibility Assignment Matrix (RAM): Tangible link between the project

Work Break Down Structure and the Resource Breakdown Structure, assigning
project work components to functional areas or individuals. Purpose: To ensure
that all key tasks and deliverables are properly assigned to the appropriate
"performing organization" and individual.
Resource Calendar: Defines resource availability according to specific periods

of time (day, week, month, etc). Purpose: To ensure that resource availability is
clearly defined and documented prior to the final specification of task plans and
schedules.
Resource Histogram: Graphical perspective of resource allocation and utilization

against a defined time scale. Purpose: To pinpoint specific periods in time where
resources may be over-allocated, and to correct related scheduling problems.
Part Two: Process
Resource Management: The global process for managing the allocation,

application and utilization of resources throughout the project lifecycle. Resource
management begins with project initiation, when resource needs and strategies
must be analyzed, specified and accepted as part of the project "charter".
Resource Planning: The process by which resource strategies are created,

involving the identification of resource requirements, skills requirements,
scheduling requirements, risks and related contingencies.
Resource Allocation (alternatives: Resource Loading): The distribution

(assignment) of individual (and/or group) resources to project tasks and activities.
Resource Leveling (alternatives: Resource Optimization, Resource Limited

Scheduling): An approach to project scheduling when start and finish dates are determined by
resource availability.
Resource Smoothing: (alternatives: Time Limited Resource Scheduling) Similar to
resource leveling, except that in the smoothing process, the determined project "end-date" cannot
be changed to account for resource limitations. Activity rescheduling can only occur within
available activity/task float. (More about Scheduling)
Part Three: Concepts & Components
Resource Pool: The collection of potential resources available for a given project
or group of projects. The resource pool can include internal and external
resources. Usage: the resource pool is used as part of resource planning and
allocation.
Resource Set: A group of resources sharing the same skills and/or characteristics,
allowing for "interchangeable" allocation. Usage: the resource set is used to
facilitate planning which relies more on skills than individuals.
Resource Availability: The degree to which a given resource (or resource set) is
accessible and ready to be assigned and allocated to tasks and activities. Usage:
resource availability is the key to effective scheduling, designed to ensure that
resources are never over-committed in order to meet unrealistic completion dates.
Resource Constraints: Any issue or event placing a limitation on the availability

of a required resource. Depending on the project, timing and duration, resource
constraints can have a serious impact on project scheduling alternatives.
Constraints should be identified as soon as resource requirements are known.
Usage: resource scheduling and allocation.
Resource Dependency: Whenever tasks or activities require the same resource,

said tasks and activities become "dependent", and simultaneous completion may
not be possible. Usage: to identify resource constraints.
Resource Requirements: The number and type of resources needed to perform

certain tasks and to complete the project. Every project will contain specific
resource requirements, considering goals, objectives, technical needs, business
needs and related issues. Usage: resource requirements are analyzed during the
project initiation phase, to create the scope of work and estimate project costs.
Resource Offset: The specific period of time (expressed as hours, days, weeks)
existing between a scheduled "activity start" and the need for a given resource.
Usage: resource offsets can be used to identify "windows of opportunity" for
concurrent resource scheduling.
Resource Based Duration (alternative: Resource Driven Task Duration):

Applies to any task or activity for which scheduling is dependent upon the
availability of specific, scarce resources. Usage: to identify tasks suitable for
resource leveling and smoothing.
Related Reading:
Project-Speak: The Project Stakeholder
Project-Speak: The Critical Path
The Role of the End-User in IT Projects
How to Create the Project Job Profile
WORKBOOK PRODUCTS:
Jumpstart your projects with a timely definition of requirements and deliverables, as you
take positive steps towards success with a careful analysis of key planning variables.
Using the pre-formatted roadmap template, you will quickly define and document a
complete project vision, getting your projects off on the right track.
Plan communications strategies, and manage related activities, including meetings,
reporting and more.
The right set of project management standards will help you to achieve on time, on target
results for each and every project. Learn how to plan, create and implement your own set
of standards and best practices.
To take advantage of the valuable lessons "hidden within", every project should conclude
with a review of deliverables, procedures and participation. This Kit provides a fast path
to meaningful post project reviews.
HOW TO CREATE PROJECT MANAGEMENT STANDARDS

In theory, project management can be simply defined as a structured process for
achieving a specific and unique outcome. But, in practice, project management is not that
simple ....
How do you manage projects? This assessment will take you through the
issues and steps involved in creating a program of standards and practices
to set the stage for project success.

An IT Project Management program is formed as a set of practices, policies and
procedures for the selection, management and control of projects within an IT
organization. Any effective program for project management begins with an
examination of organizational characteristics and requirements....
What is the size and nature of the business you support (are you in a small
business, mid sized business, or a large corporation?)
What types of projects do you encounter?
What is the level of your internal project management capabilities and skills?
What are your internal technical capabilities and skills?
What is the nature and complexity of your technical environment?
What is your budget for project management training, tools and software
resources?
To what degree is management supportive of your project management efforts?
To what degree is IT accepted within your organization?
To what degree do you you rely on projects to support business operations,

growth and revenue?
What value placed on project management as a formal business practice?
In short, when creating a structured program for project management, that program must
fit into the overall function of the IT group and its place within the organization.
DEFINING YOUR GOALS
Within any given IT group, project management practices can range from calendars and
to-do lists to gantt charts and work breakdown structures. However these practices may
vary, the goals are usually the same ... to produce the desired project results within the
boundaries of time, costs and available resources.
Project management standards and practices should cover the following areas....
Project Organizations: to establish organizational guidelines and reporting

relationships for project teams.
Project Initiation: to specify steps for project selection, initiation and

prioritization.
Project Planning: to define project planning methods and procedures.
Roles & Responsibilities: to establish resource roles and responsibilities for
project management, planning and execution.
Risk Management: to establish risk management guidelines and procedures.
Change Management: establish change management guidelines and procedures.
Communications: structure communications and status reporting requirements.
Vendor Relationships: to establish outsourcing guidelines.
Purchasing Guidelines: to establish purchasing and cost control strategies.
Project Evaluation: to establish evaluation criteria and exit strategies for failing
projects.
Project Closure/Transition: to create guidelines for project completion,

transition and post project activities.
Project Tools: to specify requirements and standards for the selection and
utilization of project planning, reporting and tracking software.
While your program may not include all these elements, your guiding principle should be
to create a project delivery roadmap for IT staff, and to create an environment where
projects can be managed and prioritized to ensure that business goals are realized.
WHY DOES PROJECT MANAGEMENT MATTER?
Considering the nature of IT work, it is likely that any IT organization will benefit from
the creation and implementation of some form of standardized project management.
Do you need to examine your current project management standards or

adopt new ones?.....
Do you need to improve staff productivity and project awareness?
Do you need to better manage incoming project requests and other

workload?
Do you need to make better use of time and available resources?
Would you like to have better consistency in project results and processes
followed?
Do you need tangible results to demonstrate IT value to your organization?
Do you need greater control over planning and execution, increasing the
likelihood of project success?
But for all these rewards, there is also one primary risk .... that your program will become
more concerned with the mechanics of managing projects than the delivery of value and
results. In this case, management processes can become so cumbersome that they
interfere with project delivery. IT staff will find ways to avoid these processes, and your
end-users will find ways to bypass IT in key projects, thus defeating the very goals you
are trying to achieve.
To avoid these risks, be sure to carefully evaluate not only your operational needs for
project management, but also your internal capabilities for effectively executing a project
management program that provides structure, but allows for flexibility.
IMPLEMENTATION
What will it take to plan and implement an IT Project Management program?
Step One: Identify Goals - what do you need to accomplish with a project
management program?
Step Two: Identify Requirements - what type of projects do you currently
encounter and what are your expectations for the future?
Step Three: Assess Capabilities - do you have sufficient information, tools and
resources to implement an effective, realistic project management program?
Step Four: Develop Program - devise and document your project management
and identify any software/hardware tools that may be required to meet
management objectives.
Step Five: Integrate Program - incorporate your project management program
with your other operations and with cooperating areas of your organization.
Step Six: Communicate - inform and train staff on all new project management
policies, processes and procedures.
Step Seven: Implement and Monitor - put your project management program in
place and continually monitor progress and effectiveness.
CONCLUSIONS:
There is no single approach to project management - but if you cover the basics, and
tailor specifics to suit needs and capabilities, you will increase the likelihood of project
success.

All-in one planning and documentation solution designed to produce specific IT
management and project planning policies. This Kit contains information, advice, and
pre-formatted "Policy" templates.
Write your own project management standards policy using the Policy Statement
Template provided (in Word format).
Follow ready to use guidelines for creating your own set of project standards and best
practices, including 60+ questions to consider as you analyze internal needs, capabilities
and goals.
Follow the (4) "phase" process for standards development and implementation - from
"start to finish".
Apply useful guidelines to help you evaluate results, and if needed, to modify standards
as business and project circumstances change.
HOW TO PLAN DOCUMENT MANAGEMENT POLICIES

Can project success be measured by the sheer weight and volume of documents
produced? Of course not..... but documentation does matter.
Project documentation provides the means by which information and ideas are created and
shared, and it is the basis upon which decisions are made and approved. It can be said that "if its
real . its documented", and in fact all key project elements are documented in at least one or
more essential documents, ranging from the statement of work, through to the weekly status
report. As such, project document management may not be particularly glamorous, but it is a key
factor of project success.
YOU NEED A PROCESS
What is project document management?
Project document management is defined by the practices and procedures used to create,
distribute and store various types of project documentation.
Document Management Goals
To provide a mechanism for document production and control that does not add
substantial overhead to the project process.
To provide standardized formats and templates for document production.
To promote collaboration and consensus through a structured process for document

review and approval.
To facilitate document retrieval and accessibility.
To minimize documentation errors through version control and secured access.
To ensure that all documents are current and that distribution is timely.
To maintain a tangible record of project strategies, activities and decisions, for future
reference and lessons learned evaluation.
Document Management Tools

YOU NEED A SYSTEM..
To realize the goals you have to maximize the tools, and the tools may vary. From the most
complex system to the simplest filing cabinet, document management tools rely on a standard
premise . documents must be created and stored in an organized fashion, designed for
easy access and control. As such, any document management system (whether "out-of-the
box" or in-house) must address the following elements:
Input: The means by which documents are created and placed into the system. Project
document repositories may hold original documents that are created by the project team,
as well as external documents produced outside the team, including scanned reference
materials (i.e. technical manuals or contracts).
Access: The means by which access is granted and controlled.
Collaboration: The means by documents are reviewed and revised based on

collaborative (team) reviews, input and edits.
Version Control: The means by documents are tracked for changes over time. (Version
1.0, 1.1, 2.0, 2.1, 2.2, etc.). Document versions offer a visible trail of project changes and
progress, and ensure that everyone is literally working "on the same page".
Output: The means by which documents are retrieved from the repository and distributed
in print, HTML or email (or other applicable format).
Searches: The means by which documents can be found and searched (i.e. according to
keywords or for specific information).
Archival: The means by which documents can be stored and retrieved for future
reference.
Create your own document repository:
Create a relevant organizational structure for your document folders/directories.

(using project, team, document type, version, status [draft or final] to form the
structure).
Establish meaningful naming conventions considering project name, document type,

version, author and any other valid organizational criteria. Naming conventions
should provide for easy access and sorting of stored documents (i.e. for quick
identification).
Use workgroup/folder/directory rights to assign realistic access rules to determine

who can create, read, update and remove documents stored in the repository.
Create rules for document retention, purging and backup to keep documents current
and remove unnecessary documents from the repository (i.e. interim versions
offering no audit trail or reference value).

Document Management Process Implementation
The following list provides a quick four step process for your "document management"
implementation.....
Step One: Delegate responsibility and accountability.
Every mid-sized to large scale project should have a Document Repository Coordinator (often
referred to as the repository librarian). Depending on the number of documents, this may be a
full-time role or a shared responsibility, but the "role" itself is essential. The Repository
Coordinator should be responsible for the following:
To identify needs and establish project documentation procedures.
To set-up and maintain the document repository.
To respond to issues and questions.
To provide assistance to team members.
To ensure that documentation policies are enforced.
To manage document archival once the project is complete.
Step Two: Identify project documentation management needs.
What types of documents do your projects require? (considering business case

documents, project initiation documents, project plans, contracts, policy documents, work
specifications, technical documents, forms and reports).
How and when are these various documents used within the project process (what
purpose does each document serve?)
Who will have input into these documents?
Who will need access to these documents?
How do these needs and requirements apply to projects of different sizes, complexity and
visibility?
Step Three: Set documentation standards.

Documentation standards should be designed in accordance with technical capabilities, and
scaled to suit project size and circumstances. The goal is to save time and promote consistency
by standardizing document "look and feel", while providing content guidelines to ensure that all
documents convey essential information. As such, any established documentation standards
should address the following issues:
What software will be used to produce the various types of documents?
What formats will be used for each type of document?
Will documentation templates be provided according to project needs, size and

complexity?
How will documents be classified for security purposes (i.e. Confidential, Public,
Departmental, Internal)?
How will documents be distributed outside the repository (i.e. email, web, print)?
Step Four: Develop your document production cycle and workflow.

The document production cycle and workflow provides the structured process by which
documents are created, revised and approved. Since project documents represent tangible proof
that project decisions and strategies are underway, any productive workflow should be designed
to ensure that these documents are created in collaborative manner, and distributed for timely
approval and acceptance. A basic documentation workflow can be laid out in five specific phases:
Phase 1: Document Draft
The document "draft" is prepared according to established standards and formats.
Phase 2: Document Review
The "draft" is reviewed by all appropriate stakeholders, and input is offered.
Phase 3: Document Revision
Review comments are considered and document revisions are made. A "pre-approval" version is
produced.
Phase 4: Document Approval
The "pre-approval" version is distributed to all appropriate stakeholders for document approval
and acceptance. Further revisions may be necessary at this point. Once all approvals are
secured, the document becomes "final", and is part of the project record. However, as the project
progresses this "final" version will still be subject to changes should project circumstances
warrant. These changes will be implemented according to established version control procedures.
Phase 5: Document Distribution
At times, project documents may be distributed outside of the project document repository (i.e. to
the general end-user community as project updates and general reference information).
CONCLUSIONS......
As with most project practices, document management specifics will vary according to needs and
capabilities, but the basic goal is the same .. to ensure that all project documents are
accessible, verifiable and available.
WORKBOOK PRODUCTS:
more.
and best practices.
PROJECT PLANNING TOOLS FOR IT-PROJECT MANAGEMENT

Key: PM = Project Management Tool
Management Tool
TO = Technology Operations Tool
GM = General
Checklists
PM Project Closure Checklist: Organize and track "project closure" tasks and activities.
PM Project Experience Checklist: Document "project management experience" for the purpose of
career planning and skills analysis.
PM Project Initiation Checklist: Record and track deliverables needed to properly begin any project.
TO Test Plan Checklist: Plan testing activities for technology deliverables
Templates
TO Customer Service Plan: Document customer service scope, goals, objectives and related
operational parameters for internal customers of IT services.
TO IT Mission Statement: Document the designated "mission" (goals, objectives and purpose) of the
internal IT organization.
PM Job Profile Template: Plan and document project "job descriptions" (roles and responsibilities).
GM Meeting Agenda Template: Prepare for and document meeting agendas.
PM Project Change Request Form: Record, document and analyze project change requests.
PM Project Issues Form: Document and track "issues" as they arise during the course of any project.
PM Project Request Form: Collect project information and request project services from pre-defined
categories.
PM Project Spending Report: Track and document project spending for specifically defined periods of
time.
PM Project Scope Statement: Document and track overall scope (work effort) for any project.
PM Project Office Mission Statement: Document the objectives, responsibilities and authority for the
internal "Project Office" organization.
PM Project Team Mission Statement: Document the assigned "mission" for your current project team.
PM Status Report Template: Document and report on the status of project tasks, activities and
deliverables.
Scorecards
TO Best Practices Scorecard: Evaluate (15) standardized technology management practices to
determine applicability to your IT environment.
GM Policy Evaluation Scorecard: Evaluate management policies according to a set of pre-defined

variables.
GM Process Evaluation Scorecard: Evaluate management processes according to a set of pre-defined
criteria.
PM Project Proposal Scorecard: Evaluate and score project proposals as part of the project selection
process.
PM Project Risks Scorecard: Document and analyze project risks.
PM Project Skills Scorecard: Evaluate project skills readiness.
PM Project Status Scorecard: Evaluate overall project status according to a set of pre-defined criteria.
TO Service Objectives Scorecard: Evaluate IT service effectiveness according to a defined scoring
system.
TO Software Evaluation Scorecard: Evaluate potential software product purchases according to a set
of defined criteria, costs and budget comparisons.
GM Staff Burnout Scorecard: Evaluate staff morale and related "burnout" warning signs.
Worksheets
GM Analysis Framework Worksheet: Plan and document the "analysis process" for any project,
problem, product review, or strategic planning activity.
PM Assumptions and Constraints Worksheet: Document and track identified "assumptions and
constraints" for any type of project.
TO Change Control Worksheet: Identify and track scheduled systems changes (upgrades, patches,
configuration updates, etc.).
PM Checkpoint Planning Worksheet: Identify and document project checkpoints (to monitor project
progress).
TO Moves, Adds & Changes Planning Worksheet: Document and track the tasks and issues
associated with technology related "moves, adds and changes".
PM Outsourcing Impact Worksheet: Analyze the "impact" that outsourcing may have on a given
project.
GM Policy Planning Worksheet: Track and plan management policies, documenting details, production
tasks, and key content elements.
PM Project Acceptance Criteria Worksheet: Document and evaluate project acceptance criteria.
PM Project Sizing Worksheet: Document and analyze project sizing characteristics. Project size will
determine the effort, attention and resources to be assigned and dedicated to a given project.
PM Quality Management Worksheet: Document and analyze the scheduling and cost overhead to be
added to a project through the application of quality management strategies and tasks.
PM Requirements Planning Worksheet: Document the issues and procedures relating to the
"requirements collection" process for projects.
PM RFP Evaluation Worksheet: Analyze RFP (request for proposal) responses as part of the project
procurement process.
GM Scenario Planning Worksheet: Document "scenarios" to be used as the basis of strategic planning,
for projects, services and strategies.
TO SLA Requirements Worksheet: Identify and document requirements for technology related
"Service Level Agreements".
PM Stakeholder Analysis Worksheet: document and analyze "project stakeholder" roles, interest and
influence. The results of this worksheet can be used to plan organizational and communication strategies.
PM Work Breakdown Structure (WBS) Worksheet: Document and plan key elements of the project
WBS (Work Breakdown Structure).
PROJECT-SPEAK: SIZING GUIDELINES

Every useful set of project management practices must account for variations in project size. For
clarity and structure, projects are most often sized in categories of "small", "medium" and "large".
We use these designations to put projects in perspective.... to determine the extent and degree to
which structured management methodologies should be applied within any given project.
Project management practices are meant to ensure that projects can be completed in a
structured fashion - on time, on budget and producing expected results. But the process should
never be allowed to overtake the project. As such, project size variations must be considered as
management practices are developed and applied.
Why does sizing matter?

When it comes to projects and practices, one size may not fit all. Project size is a determining
factor of "process scope", most simply defined as the degree and extent to which project
management practices are formally applied.
Project Size Defines Process Scope.
Project sizing is a "must consider factor" for project planning, ensuring that plans and activities
are relevant, and that resources are properly used and allocated. This is particularly important in
the multi-project environment, where simultaneous projects must compete for funds and human
resources. It is unwise and impractical to take a "one size fits all" approach to managing projects.
Small project methodologies would never fit a large scale project, and any small project would
easily be overtaken by the weight of overly detailed procedures and practices.
Make the Process Fit the Project.
Any useful set of project management practices must account for variations in methodology
according to "project size". Size appropriate methodologies can be defined according to the
following variables:
1. Applicability: Is the process appropriate to the project?
2. Formality: If the process is appropriate, should it be applied in a formal (pre-defined) or
informal manner?
3. Flexibility: How much flexibility will be allowed?
4. Documentation: What types of documents will be required?
5. Detail: What level of detail will be required in any documents?
How will project sizing be integrated into each of these essential project
management practices and procedures......?
Project Selection
Initial Project Definitions
Project Kick-off Events and Activities
Planning and Scheduling
Project Budgeting
Project Progress Measurement
Resource Management
Communications Management
Change Management
Issues Management
Risk Management
Status Reporting
Document Management
Closure and Transition
Project Sizing Guidelines....

To develop effective sizing guidelines, you must be prepared to identify specific measurement
variables of project size, as well as the specific criteria to be applied within each variable
category. These "criteria" will create the thresholds upon which size is determined and applied.
The "sizing" process is part science and art. Every project has a mind of its own, and may not
always fit neatly into specific size categories. As such, it is best to apply sizing guidelines at
multiple levels, ensuring that all variations and nuances are considered.
*Please note - the sizing criteria listed below are presented as examples. Specific criteria will vary
by individual business circumstances.
Level One Sizing Variables
Sizing Criteria*
Sizing Variable
Small
Medium
Large
Project Duration
Six months or less
6 12 months
12 months or
more
Less than 10K
10K 100K
100K or more
Less than 5
5 - 15
15 or more
Project Cost
Project Resources
Level Two Sizing Variables

Sizing Criteria
Sizing Variable
Small
Medium
Large
Strategic Value
Minor connection to
overall business
strategies.
Moderate
connection to
overall business
strategies.
Significant
connection to
overall
business
strategies.
Organizational Impact
Financial Impact
Visibility to Senior
Management
Complexity
Dependencies
Impact to a single
business unit.
Impacts 2 4
business units.
Impacts more
that 5 business
units.
Minor impact on
revenue, expenses
or transactional
volume.
Moderate impact
on revenue,
expenses or
transactional
volume.
Significant
impact on
revenue,
expenses or
transactional
volume.
The project is of
minor interest to
senior
management.
The project is of
moderate
interest to senior
management.
Senior
management
will be very
interested in
this project.
The problem and

solution are defined
and easy to
achieve.
The problem
and solution
require
refinement and
will be
somewhat
difficult to
achieve.
The problem
and solution will
be difficult to
define and
achieve.
No links
(dependencies) to
other projects.
Minor links to
other projects
(creating low
risk).
Significant links
to other
projects.
Striking a Balance
In order to properly size any project, these level one and level two variables must be balanced to
ensure that the appropriate management methodologies can be applied. But, time, costs and
resources cannot be the sole factors of project sizing. As analytical factors, they may be initially
determinative. In point of fact, lengthy, high cost projects, with sizeable project teams, will likely
require "large project methodologies" regardless of any specific level two factors.
In contrast, a short duration, low cost project can still be technically complex and therefore highly
visible to senior management.. In this case, "small project methodologies" may not be wholly
appropriate, and you may need to break out of the small project mode. For example, you might
adapt your management approach to include some of the more formal communication or
documentation procedures than would ordinarily be suited to a small project.
Conclusions....
Projects are often similar, but are rarely the same. Projects must be managed with an eye
towards that reality, using practices built on the similarities and embracing the differences. The
application of multi-level sizing guidelines will help you to evaluate projects and employ practices
designed to deliver process productivity and project success.
Ideas into Action: The Project Sizing Worksheet

RELATED PLANNING TOOLS.....
Write your own project management standards policy using the Policy Statement
Template provided (in Word format).
Follow ready to use guidelines for creating your own set of project standards and best
practices, including 60+ questions to consider as you analyze internal needs, capabilities
and goals.
Follow the (4) "phase" process for standards development and implementation - from
"start to finish".
Apply useful guidelines to help you evaluate results, and if needed, to modify standards
as business and project circumstances change.

HOW TO WORK WITH PROJECT STEERING COMMITTEES

The primary purpose of a steering committee is to provide overall guidance and direction for a
single project, or set of projects. As such, steering committees can be of great help to any
overworked project manager, providing tangible evidence of management support, as well as
much needed guidance through problems and sensitive political issues. But, if improperly
organized, steering committees can create more problems than they solve.....
Steering committees can become excessively bureaucratic, taking valuable time

away from productive project activities.
Steering committees can micro-manage, stepping on the authority of the project

manager, causing that individual to lose valuable credibility and influence.
Steering committees may be more focused on politics than projects, and as such,
may fail to support the project manager who has made unpopular, but necessary,
project decisions.
To avoid these pitfalls, project steering committees should be organized and staffed according to
specific business needs and project requirements.
Do you need a steering committee?....
The Decision Factors:
Project Duration
1 month or less
2 - 5 months
6 months +
Project Complexity
Low
Moderate
High
Project Visibility
Low
Moderate
High
Single Unit or
Operation
Multiple Units or
Operations
Extensive
Organizational
Impact
Project Risk
Low
Medium
High
Project Costs
Low
Medium
High
Outsourcing Involvement
None
A portion of the
project
The entire project
Not Necessary
A Good Idea
A Must
Project Reach
Steering Committee
Value
Considering these decision factors, it is likely that steering committee oversight will be worthwhile
and absolutely necessary, for lengthy, complex projects, that are highly visible, risky and costly,
impacting multiple business units and operations. However, considering the impact that any
technology project can have upon a business, it is wise to consider steering committee value for
all projects in a practical light ,,,, will it help get the project done on time, on budget and as
required?
Steering Committee Structures, Roles & Responsibilities:
Depending on organizational issues and project requirements, steering committees can be
created to oversee individual projects, groups of projects, or some combination thereof. Whether
a steering committee is assigned to one or more projects, committee structures, roles and
responsibilities should be clearly defined.
In all likelihood, you will face the following questions as you set up your steering committee:
What is the optimum size for the committee?
Who should be involved?
What is the committee's mission, role and level of authority over the project manager and
his/her team?
Will the committee oversee one project or multiple projects?
Will participants be assigned for the duration of a single project, or rotated to allow for
multiple perspectives and views?
Who will chair the committee?
Will all participants have an equal vote in decisions?
Will there be non-voting members?
Guidelines:
In order to ensure that any steering committee is structured to facilitate and enhance project
completion, a few practical guidelines can be followed:
The size of the committee should be kept as small as possible, minimizing politics and
making it is easier to get things done.
Participants should have sufficient knowledge, interest and expertise to contribute to the
project oversight process.
Participants should have a stake in the outcome of the project.
All key project and business functions should be represented as needed to support the
project or group of projects.
Once assigned, all committee members should be required to attend all meetings and
participate as needed.
In addition, to avoid political problems and micro-management
difficulties, steering committee roles and responsibilities should be
clearly defined and communicated. The primary function of the steering
committee is to guide the project, not to manage the project.
Steering committee members should take a "hands-off" approach to the project, providing
strategic direction, but trusting the project manager and the team to do its job. To that end,
steering committees should be structured to perform the following functions:
To provide strategic oversight for the project or for multiple projects.
To maintain project focus and direction, ensuring that the project stays on track,
according to defined goals, requirements and deliverables.
To resolve conflicts and make decisions regarding changes to project scope and
deliverables.
To provide management support, direction and advice to the project manager and the
project management team.
To monitor project progress and respond to problems as needed on a management level.
To ensure that projects are in alignment with changing business circumstances and
objectives ... providing a global perspective that may not otherwise be available to an
individual project team.
CONCLUSIONS.....
As a busy project manager, it may seem that the steering committee exists solely to oversee your
work. But, in reality, you also have a responsibility to yourself, and your team, to ensure that the
steering committee is ready and able to serve your needs. To that end, you should:
Create a steering committee mission statement to clearly establish and communicate the
goals, structure and authority of the committee.
Establish procedures and activities to ensure effective steering committee participation,

and to keep the members properly informed.....
Hold regularly scheduled committee meetings.
Produce regular status & issue reports.
Establish emergency issue escalation procedures.
Try to cultivate and maintain positive working relationships with as many steering
committee members as possible. Be honest about project status, ask for help whenever
needed, and try to keep the committee "on your side".
Ideas into Action: The Stakeholder Analysis Worksheet (QuickTool)

WORKBOOK PRODUCTS:
Process Kits: All-in-one planning solutions designed to produce "process" deliverables for
projects and IT services. Process Kits contain information, advice, interactive planning forms,
and pre-formatted "Plan" templates.
Survey Kits: All in one planning solutions designed to collect performance feedback for projects
and IT services. Survey Kits contain information, advice, electronic survey forms, and preformatted "Lessons Learned" templates.
Policy Kits: All-in one planning and documentation solutions designed to produce specific IT
management and project planning policies. Policy Kits contain information, advice, and preformatted "Policy" templates.
PROJECT-SPEAK: ASSUMPTIONS AND CONSTRAINTS

Few projects begin with absolute certainty. If we had to wait for absolute certainty, most projects
would never get off the ground. As projects are planned and executed, some facts and issues
are known, others must be estimated. Estimation is an art, with many fine points to finesse
between certainty and wishful thinking. You can't just hope you have the resources you need to
do the job, and you can't wait until every resource is available to begin. You have to manage and
mitigate using informed "assumptions and constraints".
Assumptions and constraints form the basis for project planning, filling in the gaps between
known proven facts and total guesswork. Each assumption is an "educated guess", a likely
condition, circumstance or event, presumed known and true in the absence of absolute certainty.
Each constraint is a limiting condition, circumstance or event, setting boundaries for the project
process and expected results. Once identified, these assumptions and constraints shape a
project in specific, but diverging ways - assumptions bring possibilities, and constraints
bring limits. Consider this example:
A defined budget is a fact. i.e. $10,000 has been allocated to complete a given project.
The belief that the budget is sufficient to complete the project on time and as required is
an assumption. This assumption should not be a guess, it should be the result of a
planned, verified budget estimate.
The need to modify deliverables and adapt the schedule to suit the budget is a
constraint.
The chart below further illustrates these similarities and distinctions:

Assumptions
Constraints
Characteristics
Condition, circumstance or
event.
Condition, circumstance or
event.
Impact
Allow the project to proceed.
Restrict and limit project

execution.
Process
Must be analyzed and

monitored to ensure validity
and relevancy as the project
proceeds.
Must be identified and

incorporated into the project
plan to ensure that the plan is
realistic.
From initiation to closure, assumptions and constraints set the stage for project planning and
execution. As the project is planned, assumptions and constraints will be used to define and
shape tasks, schedules, resource assignments and budget allocations. As such, each is used to
manage an otherwise uncertain future, laying out a roadmap for how the project will proceed. At a
minimum, as the project begins, assumptions and constraints must be defined for one or more of
the following elements:
Effort: The estimated tasks and activities required to manage the project and produce
deliverables.
Schedule: The estimated tasks and events needed to complete the project, organized
into a structured sequence to meet a specified project end date.
Resources: The estimated staff resources needed to complete the project, according
to number, type, work hours, and skills.
Budget: The estimated cost of the project, allocated to tasks, resources and phases
as needed to complete the project.
Vendors and Procurement: The anticipated performance of contractors, vendors

and suppliers to deliver goods and services according to contracts and project
requirements.
Management Process: Management standards can serve as a constraint on project

performance, adding quality control overhead.
Step by Step: Managing Assumptions and Constraints

1. Identify and Challenge - The first step in the "assumptions and constraints"
management process is identification. As assumptions are identified, each must be
viewed with an appropriate degree of skepticism. Assumptions cannot be mere
guesswork or wishful thinking. For example, you can't just hope that the budget will be
sufficient, you have to examine and verify budget estimates to get as close to certainty as
possible. In turn, constraints must also be viewed skeptically, with an eye towards
possible elimination. Constraints pose restrictions, and any relief from these restrictive
elements would be welcome. But, if constraints cannot be eliminated, then appropriate
workarounds must be developed.
2. Assess - Assumptions should be evaluated from a long term perspective, according to
confidence level (i.e. How confident are you that this assumption will be proven correct?),
followed by a related "if-then" risk counterpart analysis (i.e. If this assumption is proven
incorrect, what will be the likely consequences for the project?). During the course of this
analysis, the "impact of the incorrect assumption" must be determined. Impact can
be weighed at various levels, from serious (threatening successful or timely project
delivery), to moderate (absorbable impact on deliverables, schedules or costs), to minor
(insignificant impact on deliverables, schedules or costs). Depending upon the assessed
confidence level and related impact, a full risk assessment may be required. If you have
high degree of confidence that a given assumption is true, then further analysis may be
unwarranted. Lower confidence and higher impact would probably require further
analysis and the related risk assessment.
In contrast, constraints must be evaluated from a short term perspective, according to
immediate impact - i.e. How does a given constraint limit or refine the project in one or
more respects? For example, product availability constraints can impact multiple
elements of a single project. Product delays can elongate the project schedule, add to
costs, and negatively impact resource availability. As constraints are assessed, all points
of impact must be determined.
3. Incorporate - Once assumptions and constraints are identified and assessed, they must
be incorporated into the relevant portion of the project plan. Assumptions, combined with
known facts, will drive the formation of the project plan, providing the actionable basis
(albeit with varying degrees of certainty) for planned tasks, schedules, budgets and
resource assignments.
Constraints must be factored into the project plan from the start in the form of stated
"workarounds". These workarounds will mitigate constraint "impact" by providing the
means for the project to move ahead despite the existence of constraining factors (i.e. A
schedule change allows for concurrent, non-dependent work to proceed even if there are
delays in product delivery. This scheduling workaround will prevent an overall schedule
delay).
Unidentified constraints will not just disappear, they will likely pop up at some later point
as full fledged project problems. Consider this example: You are working on a project
where specialized technical skills are required. You estimate that these specialized
resources will be required for (40) hours per week during the month of June, and you
prepare your project plan based on this assumption. However, you fail to account for the
fact that these resources will only be available for (20) hours per week in the month of
June. Initially, this resource limitation was a constraint, but since it was not identified at
the outset, once June rolls around, it becomes a major problem.
4. Control - Initial assumptions and constraints are rarely static. As the project evolves,
assumptions will be proven true or untrue. Changing circumstances may eliminate or
modify previously identified constraints. In either case, you must be prepared to react,
with contingencies, workarounds and modifications to plans and deliverables. To ensure
a constant state of readiness, identified assumptions and constraints must be tracked
and monitored throughout the project process. In addition, assumptions can be factored
into the plan via "checkpoints" (i.e. the point at which the assumption will be tested
(proven correct or incorrect (in part or whole). These checkpoints can then be monitored
to ensure that working assumptions are valid, and if not, to take corrective action.
5. Review - Once a project is complete, assumptions and constraints should be reviewed
as part of an overall "post-project" review process, to evaluate all steps taken for
identification, assessment, incorporation and control. This review should consider
quality, accuracy, effectiveness and omissions (missed assumptions and/or constraints

that should have been discovered as the project began).
Conclusions:
Projects are filled with varying degrees of certainty and uncertainty. As projects begin, known
facts must be supported by informed assumption, and managed according to identified
constraints. As the project proceeds, changes will occur, as reflected in an ongoing series of
revised "assumptions and constraints". Using a structured process for identification, assessment,
validation and control, your informed, but uncertain, "constraints and assumptions" will lead to
certain success.
Ideas into Action: Assumptions and Constraints Worksheet (Quick Tools)
WORKBOOK PRODUCTS:
more.
and best practices.
PROJECT- SPEAK: CRITICAL PATH ANALYSIS

What's on your critical path?
Important tasks? Sure. Really important tasks? Of course. But is that all there is? After, all
project tasks are important in one way or another, and even the most important task may not lie
on the critical path.
Within any project, the critical path is more than just a series of important tasks .... it is a means
for scheduling and management that relies on connections and consequences as a basis for
planning project tasks and timelines.
Critical path tasks are not deemed "critical" on the basis of value or visibility, but on the basis of
dependencies, which determine the overall length of the project. Since critical path tasks are
connected, any delay in one, can lead to a delay in all....
As such, the critical path tells you what you need to do to get your project done on time.
Critical Path Analysis:
As a project management practice, critical path analysis provides value in four key respects:
1. To estimate overall project duration.
2. To create a logical sequence of project tasks.
3. To track project progress and identify potential delays.
4. To identify potential "fast-track" possibilities.
The Basics: Critical Path Concepts
Critical path analysis relies on a few simple assumptions:
Projects are made up of tasks.
Tasks are combined to form a timeline.
Within this timeline, tasks are either concurrent (can occur simultaneously) or
sequential (one task cannot begin until the predecessor [superior task] is complete).
Sequential, dependent tasks make up the critical path.
Find Your Critical Path:

Critical path analysis begins with a task list, identifying all the key tasks required to complete the
project at hand. This task list can be broken down into the following elements:
Tasks: Specific work activities.
Predecessors: Tasks that must be completed before any subsequent, dependent task
can begin.
Durations: Task time estimates (from start to completion).
Early Start Time: The earliest point in the schedule at which a task can begin (based on
predecessor connections).
Early FinishTime: The earliest point in the schedule at which a task can finish (based on
predecessor connections and estimated task durations).
Latest Start Time: The latest point in the schedule at which a task can start without
causing a delay in the overall timeline.
Latest FinishTime: The latest point in the schedule at which a task can finish without
causing a delay in the overall timeline.
Critical Path in Practice:
Example: You are planning a project with five key tasks, and have developed the following
assumptions regarding task connections:
Task
Task 3 cannot begin until Tasks 1 and 2 are completed.
Task 4 cannot begin until Task 2 is completed.
Task 5 cannot begin until Task 3 is completed.

Predecessor
Duration
Earliest Start
Time
Earliest Finish
Time
Latest Start
Time
Latest Finish
Time
None
1 week
Week 1
Week 1
Week 2
Week 3
None
2 weeks
Week 1
Week 3
Week 1
Week 3
1, 2
1 week
Week 3
Week 4
Week 3
Week 4
2 weeks
Week 4
Week 6
Week 5
Week 7
1 week
Week 6
Week 7
Week 6
Week 7
Looking at this example, you will note the similarities between Tasks 2, 3 and 5. Each of these
tasks have the same early and late "starts" and "finishes", indicating a lack of "float time".
Because of the identified dependencies, each of these tasks must begin and end on time, or the
subsequent, dependent task will be delayed, thus elongating the overall project timeline. Any
slippage in one may lead to a slippage in all. As such, these tasks constitute the critical path.
On the other hand, Tasks 1 and 4 have a more independent nature. Looking at the chart, we can
see that Task 1 will take one week to complete, and because of the identified dependency, it
must be completed before Task 3 begins. Task 3 must begin on Week 3, therefore, Task 1 must
be completed by the start of Week 3. Since Task 1 only requires one week to complete, planning
options exist. Task 1 can be started on Week 1 or Week 2, and can still finish in time for Task 3
to start. As such, the start and finish of Task 1 can "float" without impacting any other task or the
overall timeline..
Task 4 also has float, but in a different way. Task 4 cannot begin until Task 2 is completed, but
there are no subsequent tasks dependent upon the completion of Task 4 itself. The end point of
Task 4 is determined by the end of the project itself, or the latest finish time of the final project
task (Task 5). Since the project is set to complete on Week 7, Task 4 must be completed by that
time. Since it will take 2 weeks to complete Task 4, the latest starting point for Task 4 is Week 5.
Since it is possible for Task 4 to begin on Week 4, then Task 4 has a float of one week. As such,
Task 4 can begin on Week 4 or Week 5 without impacting the end point of the project. If the
completion of Task 4 were to extend beyond Week 7, the entire project timeline would be
delayed.
From a practical standpoint, critical path analysis is all about "breathing room" .... to identify the
tasks that must start and end at a specific point in time, versus those tasks which offer scheduling
flexibility. Any worthwhile project management software will calculate critical path for you based
on the tasks, dates and dependencies entered, but the logic behind these calculations should not
be a total mystery, for it is the human element that must respond to project issues and changes
on a daily basis ... in real time.
Critical Path Calculations:

As you can see from the chart above, critical path is all about timing .... finding the earliest and
latest points at which tasks can begin and end. The calculation of earliest start times (EST) and
earliest finish time (EFT) is used to create the project schedule. The calculation of latest start
times (LST) and latest finish times (LFT) is used for schedule management, delay resolution, and
fast-track planning.
Calculations: Early Starts and Finishes
EST of tasks with no predecessors = First logical starting point.
EST of tasks with predecessors = Predecessor EFT (Earliest Finish Time).
EFT of tasks with no predecessors = Estimated task duration.
EFT of tasks with predecessors = (Task EST + Estimated task duration).
On the other side of the coin, latest start (LST) and latest finished times (LFT) are backwards
calculations, considering the earliest starting point of the first subsequent task, minus the
expected duration of the task under calculation. To calculate LST and LFT, you will start with the
latest finish time and work backwards to calculate the latest possible start time.
Calculations: Late Starts and Finishes
Step 1 - Finding the LFT (latest finish time):
Considering the estimated "earliest start time" of any subsequent dependencies, what
is the latest finish time for this task?
Task LFT = EST of the first dependent task.
(Example: LFT of Task 1 = EST of Task 3)
Step 2 - Finding the LST (latest start time):
Considering the identified "latest finish time", what is the latest starting time for this
task?
Task LST = (LFT Task duration).
(Example: LST of Task 1 = (Task 1 LFT - Task 1 Duration)).
CONCLUSIONS.....
Considering the nature of most projects, critical path analysis can be a mind numbing experience.
But every project schedule is a living entity, which must be continually monitored and
manipulated. For simplicity and manageability, it best to break every project down into smaller,
logical pieces, managing critical path for discrete phases and milestones, as opposed to the
unwieldy whole.
WORKBOOK PRODUCTS:

HOW TO USE ROI TO PRESENT IT VALUE

If you expect to receive acceptance and recognition for the true business value of IT, then you
must be able to express IT expenditures in standard business "value" terms. This is not a natural
tendency for IT managers, who have probably risen to the management ranks by virtue of their
technology skills more so than any accounting skills. In addition, IT value cannot always be seen
in the "numbers", but also lies in the intangibles of productivity, performance and staff morale.
Yet, as a tool, ROI can be a powerful measure of IT investment value.
Any IT related ROI calculation will express IT value in strict monetary terms. IT ROI can be
defined as the expected financial return to be realized from an IT investment over a period of
time. ROI is a standard formula for determining the overall value, benefit and worth of a given
expenditure or project in tangible business terms.
To begin any ROI analysis, you must first have a good understanding of your overall goals and
objectives. When conducting an ROI analysis, whether for the purchase of hardware assets,
software assets, IT services or some strategic technology initiative, the standard goal is to
provide a useful metric for meaningful decision making. In other words, to view IT expenditures
according to tangible business benefits provided in order to make effective purchase and
expense decisions.
There are many different types of formulas for calculating ROI, but one of the most effective
methods for determining IT related ROI is through payback analysis.
What is payback analysis?
Payback analysis is a calculation of the expected time to break even, or the
length of time it will likely take to realize a positive return on an IT investment.
The benefits to be accrued from any IT expenditures will likely accrue over
time. However, the life expectancy of many IT expenditures is limited by
business circumstances and technology changes. For example, in the past
few years, technology changes have occurred at a very fast pace, and
frequent updates to installed technology may be necessary just to keep up, or
to maintain stable operations. As such, in IT, the time to break even
calculation can be a very powerful analytical figure, more so than a straight
calculation of a percentage ROI.
For example, if you are planning to upgrade desktop hardware, and you expect this new
equipment to fill your needs for three years, a payback in one year would be indicative of a
positive investment, whereas a payback in five years would have much lesser value.
Calculating Payback:
In order to calculate ROI in terms of the time to break even (i.e. payback), you will need to
determine three key factors:
Costs (The investment dollars)
Benefits (Revenue, profit, cost or productivity savings)
Calculation Period (The time period over which the aforementioned benefits are
calculated)
Factor 1 - Costs:
The cost factors involved in any IT expenditure will depend on the specific nature of the
investment under examination. Most IT expenditures would involved the following types of cost
factors:
Hardware
Software
Infrastructure
Facilities
Design and Development Expenses
Installation Expenses (tools, equipment & staffing)
Maintenance Expenses
Training Expenses
Factor 2- Benefits:
The second element of the payback equation is the estimation of the benefits to be derived from
the investment. Depending on your organization, and nature of the specific expense, IT
investments may provide a source of revenue or enhanced profitability, and these types of
benefits would be determined according to expected revenues or enhanced profits. However, in
most cases, IT expenses provide benefits that are realized through cost savings and workplace
productivity enhancements. As such, IT investment benefits can include:
Revenue (if applicable)
Increased profits
Productivity Gains (save time)
Cost Reductions
In order to calculate payback, you must be able to translate any related benefits into tangible
facts and figures.
For example, if you expect to realize productivity gains from your proposed IT investment, you
must be able to quantify those gains in terms of the number of employees who will likely become
more productive, the number of work hours to be saved, and the value of those work hours based
on salary, benefits and other staff related expenses.
Factor 3 - Benefits Calculation Period:
The benefits calculation period is an expression of the period of time used to estimate investment
benefits, which can include revenue, profits, cost savings or productivity savings. In all likelihood,
the benefits calculation period will be 12 months.
The Payback Analysis Formula:
Consider this example:
The Formula:
"Costs" / "Benefits" x "Benefits Calculation Period" = Payback
The Factors:
Costs of the IT Investment: $25,000
Benefits to be Realized:
$100,000
Benefits Calculation Period: 12 Months

The Payback Calculation:
(0.25) x 12 = 3 months
In this example, the time to break even for this $25,000 investment would be three months,
which, depending on the life expectancy of the investment, would probably offer a great return.
This measure of ROI can be a very useful tool for the busy IT manager,
looking for tangible ways to express IT value in standard business
terms. However, it is important to note that ROI is but one
measurement.
CONCLUSIONS.....
IT expenditures often provide benefits that cannot be expressed in strict financial terms, which
can include security, systems performance and reliability, end-user support, training, competitive
advantage, and staff morale. ROI analysis is a tool for the IT manager, along with the skills
needed to communicate, negotiate, and convince business management that IT value must be
viewed as whole, both in financial terms and for all intangibles that IT services and technology
itself has to offer.
MORE ABOUT VALUE-ADDED IT MANAGEMENT.....

MOVING BEYOND ANALYSIS PARALYSIS

When every project, plan, decision, and solution depends upon the meaningful analysis of goals,
requirements, alternatives and consequences, can there ever be too much analysis? Can there
ever be too much input? Can reasonable deadlines be set when new information is always
waiting around the corner?
The answer to these questions is a resounding yes! It has to be. Once "analysis" crosses the
cost/benefit line, it becomes counter-productive, impeding forward movement and tangible
progress. In common terms, this is known as "analysis paralysis".
What is analysis paralysis?
According to the Wikipedia encyclopedia, analysis paralysis occurs when "... the opportunity
cost of decision analysis exceeds the benefits. Analysis paralysis applies to any situation
where analysis may be applied to help make a decision and may be a dysfunctional
element of organizational behavior. .... In software development, analysis paralysis
manifests itself through exceedingly long phases of project planning, requirements
gathering, program design and modeling, with little or no extra value created by those
steps."
Analysis paralysis is an ever present "risk" for IT projects and services. Analysis is everywhere projects, problems, product reviews, operational strategies. Information comes in, data has to be
organized, reviewed, and considered to reach conclusions and produce results. Consider these
few examples:
Analysis as part of project management....
Requirements are analyzed to form the basis of project deliverables.
Project risks are analyzed to determine probabilities, impact and consequences.
Project performance is analyzed to identify lessons learned and related performance

improvement strategies.
Analysis as part of technology planning.....
Operational workflow is analyzed to develop targeted technology solutions, including

hardware and software systems.
Product features are analyzed to select products and form technology standards.
Future business needs and technology developments are analyzed to form ongoing
operational and technical strategies.
Business impact is analyzed to formulate disaster recovery plans.
Analysis as part of customer services....
Symptoms and diagnostic results are analyzed to solve technical problems.
Needs and priorities are analyzed to plan and deliver IT services.
End-user feedback is analyzed to identify service problems improve IT customer

services.
Are you suffering from analysis paralysis?

Analysis paralysis is characterized by "empty activity", i.e. any analysis related activity (data
collection, organization, review, investigation) that cannot be tied to specific, planned
accomplishments (goals, decisions or deliverables).
In order to maintain forward momentum, and deliver required projects and services, "analysis"
must serve a specific purpose, whether to aide a decision or produce a deliverable. Analysis
related activities must be executed to move a project or process forward. Once in "paralysis
mode", activities cease to contribute to the bottom line, becoming "empty and excessive".
Analysis paralysis is usually caused by a well-intentioned, but misplaced focus on "work instead
of results", characterized by one or more of the following:
The uncontrolled collection of excessive amounts of data.
Ongoing unproductive activities (meetings) creating an appearance of forward movement

(activity is confused with "accomplishment").
Excessive attention to process deliverables (reports and studies).
Decision avoidance ... i.e. frequent requests for changes and/or additional information
just at the point at which decisions could otherwise be made.
Fear of failure or error - "If I don't take action, I can't make a mistake".
Fear of obsolescence ... "What if something better comes along, what if some new
information is available?"
Avoiding Analysis Paralysis:
Analysis has a simple goal: to reach the best conclusion possible, based on reasonable, verified
information and informed consensus. How can this be achieved without excess? The first step
towards avoiding, or at least minimizing, analysis paralysis is to define appropriate process limits
and expectations. Analysis is not a deliverable in and of itself, it is a process used to create a
deliverable, and as such, it must be defined by specific goals, tasks, deadlines and results. This
can be achieved through the creation of an analysis framework.
Building the analysis framework.......
The analysis framework is used to establish (5) defining parameters for the ensuing process,
setting the stage for the work to be done. Using the framework, you can avoid the type of openended, undefined process inevitably leading to "analysis paralysis".
Step 1: Set process goals and objectives.
What is the driving force behind this analysis?
Why is this analysis necessary and how will it add value to the project or issue at hand?
What is the urgency?
What are the risks if this analysis is not undertaken?
Step 2: Set process limits with a defined scope.
How will this analysis be used to influence the decision, plan or project at hand? Note: If
the pending analysis cannot be tied to a specific need or result, it is time to rethink the
whole thing.
What are the expected results (deliverable) of this analysis? Note: Depending on the
project, problem or issue at hand, analysis deliverables can include decisions,
recommendations, plans and problem "plans of attack".
What is the minimal amount of information required to reach the desired result?
Can this analysis occur in "phases", to allow other work to begin even if all "analysis" is
not yet complete?
Step 3: Set a deadline.

Every analytical process should proceed along a defined timeline, with an established (and
communicated) deadline. Without a firm deadline, analysis can become a never-ending cycle of
"wait, here's some new information", or "let's have another meeting". Analysis should never be
open-ended, it should always be tied to a specific goal and a specific deadline. Any and all
changes to this deadline should be considered carefully, and allowed only when absolutely
necessary.
Step 4: Define tasks, with assigned roles and responsibilities.
How will this analysis process be executed?
Who will be involved?
What tasks are required for data collection, organization, analysis and deliverables
production?
Step 5: Establish success criteria.
Success criteria will help you to set expectations and avoid "analysis" scope creep. Defined
success criteria will also help you to respond when and if problems arise, and you are in need a
"plan B".
Conclusions ... Put Perfection in Perspective
In short, the analytical process is an essential component of project and service success.
Analysis should never be given short shrift in an effort to "just get things done". On the other
hand, at some point, analysis has to give way to action. Analysis should lead you to your best
conclusion, not necessarily to the perfect conclusion (which may in fact be beyond reach). When
it comes to analysis, strive for the "Goldilocks" principle: "not too little, not too much, but just
right".
Quick Tools:
The Analysis Framework Worksheet
Click on the link above to access the Analysis Framework Worksheet. This latest entry in our
Quick Tools series will help you to plan and document "analysis" activities for projects and
planning initiatives.
WORKBOOK PRODUCTS FROM ITTOOLKIT.COM
and best practices.
HOW TO MAXIMIZE TEAM PARTICIPATION

When you work alone, you will most likely be judged by results. When you lead a team,
you will be judged not only by results, but also by how those results are achieved.
Participation is the key to team results.
IT management is a "team sport". In practical reality, it takes a "team" to complete a
project, solve a problem and brainstorm strategic decisions. Whether you lead an
individual team or an entire department, your ability to motivate that team to success is
critical. Along the way, you will have provide encouragement, direction and inspiration.
You will also have to manage team relationships and smooth over the inevitable bumps in
the road. Within any team environment, personality conflicts and territorial disputes will
arise, and you have to either overcome or eliminate any potential roadblocks to team
success.
As a result, your first goal as a team leader or manager is to minimize these
potential conflicts by ensuring that your team is structured for maximum
participation and collaboration. The following list of steps and issues provides a
quick reference guide to maximizing team participation....
THE STEPS
Evaluate Your Needs - Why has this team been formed and what do we
need to accomplish?
Set the Stage - Plan for and create a team environment that welcomes and
encourages active participation.
Lead by Example - Turn theory into action by leading the way to
effective team participation.
THE DETAILS
Evaluate Your Needs
To cultivate optimum team participation, you must have a good handle on your
goals and overall dynamic. As such, you should be prepared to answer the
following questions....
Why has the team been formed ... for a project, to solve a problem, or to
brainstorm?
How large is the team - should it be broken up into smaller sub-groups to

foster participation and communication?
Who has been assigned to your team ... have they worked together in the
past?
Do you anticipate any internal conflicts or political situations?
Set the Stage

If you want to achieve optimum team participation, you need to let your team
members know what you expect, and what is expected from them. With that in
mind, you can lay the foundation for open participation and communication
through the following strategies and tactics.....
Be direct - ask for participation.
Define participation and set appropriate expectations - participation can

come in many forms, depending on your team situation.... i.e. in meetings,
workshops, memos, written comments and suggestions, etc.
Set the groundrules to encourage active team participation ... all ideas are
welcome and every member is to be respected.
Push for participation from the very start.
Thank everyone for their contributions - often and visibly.
Lead by Example
As a team leader, you job is to lead, and to get the team to function as a cohesive
unit. To meet this goal, you can follow a few simple steps centered around
leadership by example....
Avoid team domination ... your job is to lead, not to control. Even if you
have all the answers, let the team dynamic play out.
Uphold the groundrules ... participation levels will rise when team
members can see that all ideas are respected and given due consideration.
Ask open-ended questions to stimulate discussions.
Be sensitive to contentious situations .... team conflicts are unavoidable,

but at a team leader you can diffuse tense situations as needed with a few
strategic words and actions. For example, depending on the circumstances,
you may choose to handle a conflict head-on, or you can table a difficult
issue for a later time, when emotions have subsided. In any case, you
should avoid isolated, off-side reactions to conflicts, and you should
always be consistent in how you react to team conflict.
CONCLUSIONS
Team commitment and results are dependent upon active participation.... after all, the
whole purpose of "teamwork" is to combine resources for better results (i.e. "two heads
are better than one...."). Ideas are contagious, and the more ideas, the better, particularly
in tough economic times, when budgets are tight, and resources are limited.
Team participation can alleviate these burdens, leading to high quality, creative solutions.
Ideas into Action:

Make the most of your team resources with this series of planning quick tools....
The Project Skills Evaluator
The IT Mission Statement Template

The Meeting Agenda Template
Soft Skills are Hard to Find is a practical tool for professional skills development. Whether
you use this innovative process template for yourself, your staff, or as part of a training program,
the information and tools provided will help you to assess IT soft skills, and plan related
performance improvements. You get.....
Practical perspectives on the role of soft skills in the IT profession, and in the IT
environment.
Ready to use definitions for the seven primary categories of IT soft skills ... creativity,
leadership, teamwork and more....
An easy to follow, 3 step process for this multi-faceted IT soft skills assessment.
A (7) part soft skills assessment worksheet, filled with 175+ multiple choice questions
designed to help you evaluate soft skill needs and proficiencies.
Useful guidelines to help you analyze and apply assessment results - to create your
own Soft Skills Action Plan.
HOW TO STRUCTURE PROJECT TEAMS

Project teams are formed for a single and specific purpose - to complete assigned projects
according to plan and budget. The project team is a working unit of individual parts, sharing a
common goal, achieved through the structured application of combined skills. Unity of purpose is
essential to success, but team unity is not a given. Teams start off as a unit, but once the work
begins, the individual "parts" have minds of their own. And, in fact, individuality and creativity is a
key component of the team dynamic. The first step to team success begins with initial
organization: to assemble and organize available resources capable of working together as a
whole through the integration of individual skills, talents and personalities.
Organizational Planning: The Resource Pool Analysis
What types of resources are needed?
What resources are available?
How can these resources be organized to maximize unity of purpose, while leveraging
specialized skills and personal creativity?

Resource requirements will depend largely on the project characteristics and the skills needed for
planning, execution and implementation. The team approach to project delivery is the norm due
to the diversity of business, management and technical skills required to complete most projects.
As such, project size, scope, visibility, complexity, cost and risk variants will determine the
number of resources required, and the related skills.
Depending on the needs and characteristics of the project at hand, resources must be selected
according to the following skill requirements:
Management Requirements
Business Analysis Requirements
Planning Requirements
Technical Requirements (Design, Testing & Implementation)
Training Requirements
Administrative Requirements
Communication Requirements
Leadership Requirements
Customer Service Requirements
Note: For further information on "roles and responsibilities" planning see: Tailor Made: Project
Management Responsibilities, Is Your Project Team Ready? and Assigning Project Roles and
Responsibilities.
Every project manager would like to believe that the "sky is the limit" where project resources are
concerned, but realities usually prevail. In most cases, the pool of available resources is limited
by finances, skills and organizational boundaries. So the challenge is clear - to balance
requirements against available resources to form the most effective team possible.
The Resource Pool Analysis:
Source: Does your available resource pool contain internal resources (permanent
employees) and/or external resources (temps, vendors, consultants and contractors)?
Organizational Reach: Does your resource pool come from a single organizational unit
or will organizational boundaries be crossed?
Commitment: What percentage of the current resource pool is available on a full-time

basis and/or part-time basis?
Overlap: What percentage of the available resource pool can fill multiple roles and
perform varied responsibilities?
Ad-hoc Availability: To what extent can resources be pulled into the project as needed
to meet targeted short term needs? (i.e. expertise contributors who are not officially
assigned to the project team).
As the project team is organized, these four variables will determine overall team composition
considering:
The use of external resources. i.e. Can you hire contractors, temps and consultants, and
if so, will this help you get the project done on time and on budget?
The need to reach out to other organizational units to complete the project. i.e. Do you
need to cross organizational boundaries to get this project done? If so, what are the
organizational implications? How will resource conflicts be resolved?
The need to allocate resources based on full-time availability, part-time availability, and
multi-role overlay (one person having multiple responsibilities). i.e. Do you need a fulltime, dedicated project team? Can resources handle multiple assignments without
damaging burn-out?
The use of specialized resources, available for interim, ad-hoc project work without
official assignment to the project team. i.e. Do you have access to specialized skills?
Can the project be managed with a core team and ad-hoc assignments as needed?
In order to increase the likelihood of project success, project teams must be organized to achieve
the following goals:
To produce the required deliverables according to plan.
To use structured communication mechanisms (meetings, status reports and related

practices) to promote information flow, informed consent, decision escalation, and
problem resolution.
To cooperate and collaborate, treating all team members with courtesy and respect.
To follow assigned work responsibilities, minimizing redundancies, and leveraging

complementary skills.
To promote a positive work environments designed to encourage an open exchange of

ideas, dissent and feedback.
It's time to put the team together.....

Step 1: Pick a model. Project team structure should mirror project structure. In small projects,
with limited resources, the project structure might follow a simple linear model, where all
resources report to a single project manager, and individual responsibilities are assigned to team
members as needed. In a larger, more complex project environment, the team can be structured
as a complex model of levels and branches, reflecting major work components and functional
responsibilities. Consider the following example:
"Work Components + Project/Process Deliverables = Workgroups":
Business Requirements Workgroup: responsible for requirements planning, business

case analysis and customer interface.
Planning and Administration Workgroup: responsible for project planning and

administrative activities.
Finance Workgroup: responsible for project finances and budget management.
Technical Design Workgroup: responsible for the design of project deliverables.
Technical Testing Workgroup: responsible for deliverables testing.
Implementation Workgroup: responsible for deliverables implementation.
Documentation Workgroup: responsible for documentation deliverables.
Step 2: Lay out the organization based on reporting relationships. Once the organizational
model is selected, management levels and reporting relationships must be identified. The
structure and resulting chain of command is essential to project success, ensuring that
information flows both top-down and bottom-up, providing a clear path to decisions and
approvals.
Questions to Consider: How many management levels are needed to ensure that this project is
completed on time and on budget?
Committee Management Level: Will there be a steering committee?
Executive Management Level: Will there be project director?
Advisory Management Level: Will there be any advisory groups to guide the project?
Project Management Level: What skills and responsibilities are needed to provide dayto-day management of all project team workgroups?
Team Leader Level: What skills and responsibilities are required to provide ground level,
hands-on leadership of individual team workgroups?
Stakeholder Relationships: How will the project team interact with the project sponsor
and customers on a management level (project direction, approvals and decision
making)?
Reporting Relationships:
Obviously, reporting relationships will flow directly from the identified management levels .... the
team leaders report to the project manager, the project manager reports to the project director,
and so on. But, in the project environment, reporting relationships are more than just lines on an
organization chart. Based on the available resource pool, project reporting relationships can be
compromised by organizational reporting relationships. When project resources are "borrowed"
from varied organizational units, dual reporting relationships exist, and inevitably, conflicts will
arise. Does the staff resource answer to the project manager or the line manager? In a conflict,
does the project have priority? Undefined reporting relationships can diminish team
effectiveness. To avoid this fate, the following guidelines should prevail:
a. Resources should report to the project manager/team leader for the time they are
assigned to the project.
b. Work priorities should be identified to allow the staff resource to act with an appropriate
degree of independence.
c.
Performance evaluations should be completed by the project manager/team leader. Said

evaluations should be incorporated into the employees overall performance evaluation.
d. Assignment duration should be negotiated with the line manager before work begins.
e. Conflicts should be resolved between the project manager and the line manager.
Step 3: Pick your people and allocate to the model according the following variables:
Role(s) (Committee, Advisory, Management, Team Leader, or Team Member)
Workgroup Assignment
Source (Internal or External)
Availability (Full or Part Time) Note: Single individuals may appear in more than one
workgroup assignment depending upon availability and overlap).
Step 4: Prepare a Team Mission Statement. The team mission statement can be used to
document team structure, purpose and objective. It is the foundation upon which the team will
operate, providing a common basis for continued action. (see the Team Mission Statement
Template)
Related Reading:
Project-Speak: Stakeholders
Working with Project Steering Committees
Strategies for Team Participation
Evaluating Team Performance
HOW TO EVALUATE TEAM PERFORMANCE IN IT PROJECTS

This is the essence of the team evaluation process......
The project is over.
The deliverables are in place.
How did the team perform?
Project teams have a limited shelf life. They exist for the duration of the project, and once the
project is complete, the team is disbanded, with its members and managers returning to their
operational assignments, or moving on to the next project. But, while the organization entity is
gone, the performance legacy lives on. Team performance is a component of project success. In
this context, there are two primary possibilities... team performance will either promote or hinder
successful project conclusions. Which one applies to you?
Team Performance: Comprehensive Perspectives
Project team performance is driven by a wide range of factors, and as such, there is no single
factor for failure or success.
The Factors of Team Performance:
Project Viability: The degree to which the project was viable (i.e. a good idea) and well
planned.
Team Organization: The degree to which the project team was properly organized to
fulfill project objectives and to produce required deliverables.
Team Composition: The degree to which skilled resources were selected for and utilized
within the project team.
Team Participation: The degree to which the team participated in all project tasks and
activities.
Team Communication: The degree to which communication strategies and procedures

were utilized to promote teamwork, shared information and effective decision making.
Team Cooperation and Collaboration: The degree to which the team members
cooperated with each other to produce project deliverables, minimize conflict and resolve
problems.
Management Quality: The degree to which the project was managed effectively,
including resource allocations, issue management and team support.
Empowerment: The degree to which the project team was empowered to make
decisions, demonstrate creativity and resolve internal issues.
Work Environment: The degree to which a positive environment was provided for team
operations, ensuring a clear chain of command, and providing all required tools and
logistical resources.
Considering these diverse variables, team performance evaluations must consider multiple
dimensions of performance. These dimensions can be viewed in four primary categories:
1. Top-Down Perspectives
2. Bottom-Up Perspectives
3. Peer to Peer Perspectives
4. Customer Perspectives
Top-Down Analysis:
Objectives: The top-down analysis examines team performance from a management perspective,
evaluating the team as a whole and on a individual member basis.
Participants: Project managers and team leaders.
Primary Questions: Did the team perform as expected and required, both as a cooperative unit
and on an individual basis? Were skills properly exercised and combined? Did everyone
participate actively and positively? Were there any internal conflicts that damaged team
performance?
Bottom-Up Analysis:
Objectives: The bottom-up analysis examines management performance from a team
"participant" perspective. The goal is to measure team satisfaction with management.
Participants: Project team members.
Primary Questions: Did the project management hierarchy create an environment for success
considering planning strategies, work assignments, information, motivation, empowerment and
support?
Peer to Peer Analysis:
Objectives: The peer to peer analysis provides the opportunity for a ground level team
assessment, allowing the individual team members to evaluate each other.
Participants: Project team members.
Primary Questions: Did each team member carry out his/her responsibilities as required? Did
each team member support the "unit", by sharing information and following procedures? Did each
team member show sufficient courtesy and respect to fellow team members? Did team members
work to resolve internal conflicts?
Customer Analysis:
Objectives: The customer analysis provides the opportunity for "customer" evaluation of team
performance.
Participants: Project customers.
Primary Questions: Was the project team responsive to customer needs? Were customers
sufficiently included in team deliberations and activities? Did the team actively seek customer
input and feedback as needed?
Team Performance Evaluations: Step by Step
1. Identify your performance evaluation objectives (i.e. to improve future project
performance, improve customer relationships, or to identify and resolve performance
problems mid-project).
2. Select your performance evaluation mechanisms (i.e. surveys, interviews or informal
review meetings).
3. Identify your evaluation scope (top-down, bottom-up, peer to peer and/or customer).
4. Select your participants (entire team or a representative sample).

5. Analyze evaluation results (strengths, weaknesses and related areas for improvement).
6. Apply evaluation results as needed to suit the objectives identified in "step 1".
Conclusions.....
Once team performance evaluation results are known, the results must be applied in order to
ensure that quality performance is repeated and problem performance is avoided. The resulting
actions will depend largely upon the source .... i.e. why did the project team perform well or why
did the project team fail to perform?
Depending upon the results, corrective actions can rely on any or all of the following performance
components:
Training: To improve the management, planning and technical skills of the internal
resource pool.
External Resource Selection Strategies: To improve the quality of external resources

through contractor bidding practices or contract negotiations.
Communication Strategies: To improve the quality of communication policies and

procedures to ensure that information flows throughout the entire team structure.
Delegation Strategies: To improve management practices to ensure that tasks are

appropriately delegated to ensure efficiency, productivity and autonomous activity.
Related Reading: Delegate: It's Easier Than You Think
Project Management Practices: To improve project management practices to ensure

that project plans are realistically attainable considering schedules, costs and
deliverables.
Project Selection Practices: To improve project selection practices to ensure that

chosen projects are viable and sufficiently aligned with business objectives.
Resource Selection Strategies: To improve resource selection strategies to ensure that

appropriate resources are selected for project participation, considering availability, skills,
organizational boundaries and the use of external resources.
Team Organization Strategies: To improve team organizational structures to ensure

that project team organization effectively mirrors major work components and
deliverables.
Management Support Strategies: To ensure that visible, constant management support

is provided to the project team, providing advice, direction, validation, rewards and
recognition.
Related Reading:
Project-Speak: Lessons Learned
Organizing Project Teams: Structure for Success
Quick Tool: Team Mission Statement Template
Lessons Learned....
Customer Satisfaction Surveys....... The IT Services Survey Kit
HOW TO STRUCTURE PROJECT TEAMS

Project teams are formed for a single and specific purpose - to complete assigned projects
according to plan and budget. The project team is a working unit of individual parts, sharing a
common goal, achieved through the structured application of combined skills. Unity of purpose is
essential to success, but team unity is not a given. Teams start off as a unit, but once the work
begins, the individual "parts" have minds of their own. And, in fact, individuality and creativity is a
key component of the team dynamic. The first step to team success begins with initial
organization: to assemble and organize available resources capable of working together as a
whole through the integration of individual skills, talents and personalities.
Organizational Planning: The Resource Pool Analysis

Resource requirements will depend largely on the project characteristics and the skills needed for
planning, execution and implementation. The team approach to project delivery is the norm due
to the diversity of business, management and technical skills required to complete most projects.
As such, project size, scope, visibility, complexity, cost and risk variants will determine the
number of resources required, and the related skills.
Depending on the needs and characteristics of the project at hand, resources must be selected
according to the following skill requirements:
Management Requirements
Business Analysis Requirements
Planning Requirements
Technical Requirements (Design, Testing & Implementation)
Training Requirements
Administrative Requirements
Communication Requirements
Leadership Requirements
Customer Service Requirements
Note: For further information on "roles and responsibilities" planning see: Tailor Made: Project
Management Responsibilities, Is Your Project Team Ready? and Assigning Project Roles and
Responsibilities.
Every project manager would like to believe that the "sky is the limit" where project resources are
concerned, but realities usually prevail. In most cases, the pool of available resources is limited
by finances, skills and organizational boundaries. So the challenge is clear - to balance
requirements against available resources to form the most effective team possible.
The Resource Pool Analysis:
Source: Does your available resource pool contain internal resources (permanent
employees) and/or external resources (temps, vendors, consultants and contractors)?
Organizational Reach: Does your resource pool come from a single organizational unit
or will organizational boundaries be crossed?
Commitment: What percentage of the current resource pool is available on a full-time

basis and/or part-time basis?
Overlap: What percentage of the available resource pool can fill multiple roles and
perform varied responsibilities?
Ad-hoc Availability: To what extent can resources be pulled into the project as needed
to meet targeted short term needs? (i.e. expertise contributors who are not officially
assigned to the project team).
As the project team is organized, these four variables will determine overall team composition
considering:
The use of external resources. i.e. Can you hire contractors, temps and consultants, and
if so, will this help you get the project done on time and on budget?
The need to reach out to other organizational units to complete the project. i.e. Do you
need to cross organizational boundaries to get this project done? If so, what are the
organizational implications? How will resource conflicts be resolved?
The need to allocate resources based on full-time availability, part-time availability, and
multi-role overlay (one person having multiple responsibilities). i.e. Do you need a fulltime, dedicated project team? Can resources handle multiple assignments without
damaging burn-out?
The use of specialized resources, available for interim, ad-hoc project work without
official assignment to the project team. i.e. Do you have access to specialized skills?
Can the project be managed with a core team and ad-hoc assignments as needed?
In order to increase the likelihood of project success, project teams must be organized to achieve
the following goals:
To produce the required deliverables according to plan.
To use structured communication mechanisms (meetings, status reports and related

practices) to promote information flow, informed consent, decision escalation, and
problem resolution.
To cooperate and collaborate, treating all team members with courtesy and respect.
To follow assigned work responsibilities, minimizing redundancies, and leveraging

complementary skills.
To promote a positive work environments designed to encourage an open exchange of

ideas, dissent and feedback.
It's time to put the team together.....

Step 1: Pick a model. Project team structure should mirror project structure. In small projects,
with limited resources, the project structure might follow a simple linear model, where all
resources report to a single project manager, and individual responsibilities are assigned to team
members as needed. In a larger, more complex project environment, the team can be structured
as a complex model of levels and branches, reflecting major work components and functional
responsibilities. Consider the following example:
"Work Components + Project/Process Deliverables = Workgroups":
Business Requirements Workgroup: responsible for requirements planning, business

case analysis and customer interface.
Planning and Administration Workgroup: responsible for project planning and

administrative activities.
Finance Workgroup: responsible for project finances and budget management.
Technical Design Workgroup: responsible for the design of project deliverables.
Technical Testing Workgroup: responsible for deliverables testing.
Implementation Workgroup: responsible for deliverables implementation.
Documentation Workgroup: responsible for documentation deliverables.
Step 2: Lay out the organization based on reporting relationships. Once the organizational
model is selected, management levels and reporting relationships must be identified. The
structure and resulting chain of command is essential to project success, ensuring that
information flows both top-down and bottom-up, providing a clear path to decisions and
approvals.
Questions to Consider: How many management levels are needed to ensure that this project is
completed on time and on budget?
Committee Management Level: Will there be a steering committee?
Executive Management Level: Will there be project director?
Advisory Management Level: Will there be any advisory groups to guide the project?
Project Management Level: What skills and responsibilities are needed to provide dayto-day management of all project team workgroups?
Team Leader Level: What skills and responsibilities are required to provide ground level,
hands-on leadership of individual team workgroups?
Stakeholder Relationships: How will the project team interact with the project sponsor
and customers on a management level (project direction, approvals and decision
making)?
Reporting Relationships:
Obviously, reporting relationships will flow directly from the identified management levels .... the
team leaders report to the project manager, the project manager reports to the project director,
and so on. But, in the project environment, reporting relationships are more than just lines on an
organization chart. Based on the available resource pool, project reporting relationships can be
compromised by organizational reporting relationships. When project resources are "borrowed"
from varied organizational units, dual reporting relationships exist, and inevitably, conflicts will
arise. Does the staff resource answer to the project manager or the line manager? In a conflict,
does the project have priority? Undefined reporting relationships can diminish team
effectiveness. To avoid this fate, the following guidelines should prevail:
a. Resources should report to the project manager/team leader for the time they are
assigned to the project.
b. Work priorities should be identified to allow the staff resource to act with an appropriate
degree of independence.
c.
Performance evaluations should be completed by the project manager/team leader. Said

evaluations should be incorporated into the employees overall performance evaluation.
d. Assignment duration should be negotiated with the line manager before work begins.
e. Conflicts should be resolved between the project manager and the line manager.
Step 3: Pick your people and allocate to the model according the following variables:
Role(s) (Committee, Advisory, Management, Team Leader, or Team Member)
Workgroup Assignment
Source (Internal or External)
Availability (Full or Part Time) Note: Single individuals may appear in more than one
workgroup assignment depending upon availability and overlap).
Step 4: Prepare a Team Mission Statement. The team mission statement can be used to
document team structure, purpose and objective. It is the foundation upon which the team will
operate, providing a common basis for continued action. (see the Team Mission Statement
Template)
Related Reading:
Project-Speak: Stakeholders
Working with Project Steering Committees
Evaluating Team Performance
HOW TO ASSESS PROJECT TEAM READINESS

Projects are all about people -- even the most well planned initiative will fail if the people assigned
cannot get the job done. One of the most important tasks for any project manager is to ensure
that a project is properly staffed, and that the project team has all the resources necessary to
deliver success.
This seems to state the obvious, but project staffing can get quite complicated by simple
organizational realities. In the IT environment, projects are often staffed by personnel that have
other roles and responsibilities. IT project managers do not always have the luxury of choosing
and assigning a dedicated project team. As a result, technology projects must often be structured
to suit staff circumstances, rather than the other way around .... where project teams are chosen
to suit the project at hand.
Is your project team ready?
Here are a few guidelines, questions and tips for assessing project team readiness....
First, a few assumptions.....
In order to properly assess project team readiness, you must first clear two basic assumptions.....
Project goals, objectives, scope and tasks must be clearly defined in order to plan and
assess staffing capabilities and constraints....
The project must be broken down into manageable components (phases, tasks,
activities, dependencies and milestones) so that work assignments and scheduling
commitments can be clearly evaluated against staffing capabilities....
Assessing Team Readiness: The Questions

1. Are you sufficiently staffed to complete this project in accordance with the schedule and
completion deadline?
2. Does the project team have the necessary skills (technical, management and
administrative) to complete the project as required?
3. If not, has training been made available as needed?
4. Are you dependent on a single individual for a specific skill or expertise?
5. If so, do you have a staffing contingency plan to account for staff changes mid-project?
6. Is the project team organized for optimum productivity?
7. Have roles and responsibilities been clearly defined and communicated?
8. Has sufficient time been allocated in the project schedule to account for vacation time,
sick time, holidays, and to avoid staff burn-out?
9. Does the team have a positive attitude towards the project?
10. Are you sufficiently aware of all risks to team performance (internal conflicts, politics,
conflicting agendas and priorities, etc.)?
11. Have you obtained resource commitments from all supporting organizational units, and/or
external service providers needed to properly complete the project?
12. As the project manager, do you have all the necessary authority to assign project
resources and deal with performance issues?
Assessing Team Readiness: The Analysis
As you consider the aforementioned questions, it is important to remember that your answers,
and their relative impact, will vary according to the project at hand. A negative response is not an
automatic indicator of pending failure, nor is a positive response an automatic indicator of
success. It all depends on timing and individual project circumstances.
Here are a few guidelines to help you analyze your assessment responses, and to take
appropriate action.....
For each positive response: you are in good shape to proceed with your project, but
you should always keep a watchful eye on staffing circumstances as the project
progresses, particularly as problems or changes occur.
For each negative or "do not know" response: a negative response, or lack of
information, is not necessarily a sign that a project should be cancelled, but it is always a
call to action. Project circumstances are rarely perfect... if they were, project
management would be easy (and it certainly is not....) What matters is how problems are
approached and handled. When faced with team readiness issues, there are several
management alternatives:
Revise project plans and strategies to compensate for any problems or deficiencies.
Reduce or revise the scope of the project to allow for successful completion within
resource constraints.
Change the project schedule to suit resource availability.
Structure the project into manageable phases with smaller deliverables, and, frequent
milestones so that project progress can be closely monitored.
Clearly identify staffing constraints and issues as project risks, putting all parties on
notice of the risks involved.
Hire temporary resources or external consultants to assist in targeted project activities, or

to backfill daily operational activities.
Look to other parts of the organization for project assistance, perhaps in remote office
locations.
Establish clear and open lines of communication between management, end-users and
the project team so that staffing issues can be identified and resolved quickly.
CONCLUSIONS.....
When all is said and done, effective communication may be the most important strategy of all.
Sometimes, despite the apparent risks and problems, certain projects will go forward. But, if you
are aware of the staffing issues, and communicate the risks, you will at least have set proper
expectations. Should any problems occur, you may be able to draw upon the added credibility to
get through the tough times.
Ideas into Action:
The following quick tools will help you to manage staffing needs and issues for your projects....
The Project Skills Evaluator
The Stakeholder Analysis Worksheet
The Project Issues Form
WORKBOOK PRODUCTS:
more.
and best practices.
Top Ten Workplace Productivity
In "dictionary" terms, productivity is

the overall measure of output
generated by a given quantity of
input. In practical terms,
productivity is all about working
smart, and doing more with less.
Use time management as a tool to build professional credibility.
Overcome productivity barriers using empathy and communication.
Follow the warning signs and take steps to minimize "staff burnout".
Adjust IT operations to suit changing economic & business conditions.
Use conference calls to lessen time spent in "face to face" meetings.
Take advantage of fast-tracking to make the most of project resources.
Click on the links to learn more.....
Use "process" to minimize wasteful operational redundancies.
Size project planning activities to suit project complexity and duration.
Improve meeting leadership skills with "post-meeting" assessments.
10
Don't waste time on failing projects. Cancel them and move on.
HOW TO OVERCOME PRODUCTIVITY BARRIERS

Technology is a key driver of productivity in the workplace, having a significant impact on people,
processes and results. End-users are supposed to use technology to produce results and to
meet business objectives. In turn, IT is supposed to provide, support and maintain the
technology necessary to support these goals.
Technology and Productivity Assumptions
End-users rely on technology to get their job done.
End-users will blame technology (and IT) when they can't get their job
done.
At first glance, productivity seems a fairly obvious goal. But the real issue is not productivity itself,
but a consensus on productivity .... getting sufficient agreement and acceptance on what
productivity actually means and how it can be best achieved.
The Role of IT in Workplace Productivity
IT is responsible for the tools of workplace productivity. Technology has changed the way work
gets done, and as an operational unit, IT is responsible for the selection and operation of
technology, to ensure that key systems are continually available, reliable and suited to the needs
of the business. IT must also facilitate the actual use of technology, by providing support,
information and training. And, above all, IT must also ensure that technology solutions are
relevant, as easy to use as possible, and always appropriate to the skill levels of the end-user
community.
Considering these responsibilities, IT managers need consider the tough productivity questions....
Are your end-users aware of all the features and functionality available to them in the
hardware and software products they use?
Is the technology currently in place being used in the most effective, efficient manner
possible?
Could any of the technical solutions currently in place be used differently to improve
productivity or to solve current operational problems?
If so, how can IT act as an agent of productivity improvement within the organization?
What are the possible barriers to productivity improvement?
As an operational unit, IT is responsible for the mechanisms of workplace productivity and for
providing the tools by which those mechanisms are used. If technical productivity is not realized,
it may well be viewed as an IT failure. To avoid that perception, IT must be able to overcome
barriers to technical productivity on multiple levels:
The End-Users: who use technology and related IT Services, and may be resistant to
changes in systems functionality, appearance or performance. In addition, these same
end-users may be less than enthusiastic about IT's role and influence in their daily
business operations, preferring to "do IT themselves".
IT Staff: who support technology and may be more interested in pure technical issues
than in the merging of technical priorities with business realities.
Management: who may not see the value of technology and IT services to the bottom
line.
OVERCOMING PRODUCTIVITY BARRIERS:

Step One: Identify the source of the barrier:
As noted, barriers to technical productivity can come from many sources, including end-users, IT
staff, and company management. In order to properly manage and respond to these barriers,
you need to identify the source. This will determine your path and ultimate objectives. For
example, end-user barriers can be tackled with added training, or improved customer service, but
management barriers require a different level of finesse, and an ability to translate technical
solutions into tangible business benefits.
Step Two: Identify the reason for the barrier:
A resistance to change. Change may prove beneficial in the end, but it may not always
be welcome at the start. New technology usually involves added training, an initial loss of
productivity, and a loss of comfort with procedures and processes that may have become
well entrenched in day-to-day business operations.
A lack of time and information. In order to deliver technical productivity, there must be
some agreement amongst the end-users, IT staff and management as to what actually
constitutes productivity at any given time. This takes time and information .... time to
review and analyze current systems and procedures, and the information to compare
alternatives. In a busy work environment, this time and information may be in short
supply.
The "Not Invented Here Syndrome". End-users and management may realize the
need for productivity improvements, but may resist IT as a source of advice, analysis and
implementation. This resistance may be born out of a mistrust for IT's motives (i.e.
replacing people with technology), a lack of faith in IT's abilities or a natural protection of
perceived organizational boundaries.
Step 3: Identify the objectives:

Productivity is an ongoing need and a continual process. But, at times the need for productivity
improvements becomes even more obvious and imperative. As an operational unit, IT may be
called upon to analyze and respond to productivity issues on two levels:
As an ongoing part of the IT charter to maintain and implement technology for continual
productivity improvements.
In response to a specific need .... i.e. to change systems or procedures after a major
problem or crisis, or to respond to changing business circumstances such mergers,
relocations or reorganizations.
Step 4: Manage the process:

Whether you need tackle productivity issues as part of an ongoing effort for process
improvement, or in response to a problem or changing business circumstance, it will be much
easier to tackle the issues, and overcome the barriers, if you break the process down into a
series of manageable components.
Productivity Breakdowns:
What is the subject for this productivity review? (hardware, software, IT process or enduser workflow?)
Can you describe the process, workflow, or system as it functions today?
Is this process, workflow or system used uniformly throughout the organization?
If the workflow, process or system is not used uniformly throughout the organization, are
there any duplications of similar systems, workflows or processes in use which can be
combined to eliminate redundancies?
Does this system, workflow or process currently deliver expected results as needed and
originally planned?
Are there any specific operational issues or problems associated with this workflow,
system or process as it is used today?
What operational and technical alternatives exist for this current process or system?
If any alternatives exist, which alternative offers the most worthwhile improvements
considering the costs of change? (i.e. hardware and/or software expenditures, training,
and the loss of initial productivity through a transition period).
Based on the foregoing analysis, is a productivity change warranted or not?
Step 5: Put it all together.....

Productivity analysis and response is a complex process, involving information, understanding
and communication. As you gather and analyze information, you may find that there are barriers
to overcome ....
Start out by identifying the source of the barrier and the reason for the barrier....
Allow sufficient time for the productivity analysis laid out above....
Focus on the benefits of any new systems, upgraded systems or changes to processes
or workflows....
Communicate with end-users as often as needed to share information and break down
barriers....
Conclusions: Productivity as an IT goal.....

In order to minimize barriers to productivity, productivity reviews should become a regular part of
the IT service portfolio. Since time is always a factor, productivity reviews should be conducted
on a scheduled basis, either on an annual or bi-annual basis as needed and appropriate. These
productivity reviews should be designed to analyze and evaluate all physical and logical aspects
of technology utilization, deployment, management, maintenance and support services. In this
manner, process and productivity improvements can become an established, "managementsanctioned" IT function, easing some of the standard barriers you might otherwise face.
MORE ABOUT IT:
MANAGING STAFF BURNOUT

The Facts of IT Life .... long hours, stressful situations, and (as it sometimes seems)
thankless efforts.
Whether you work in technical support, applications development, platform design, systems
administration or project management, the IT life is both challenging and stressful.
It's hard to escape the long hours and feelings of frustration as you repeatedly watch unexpected
events play havoc with best laid plans. And, even when it is time to relax, you can't even take full
advantage of the freedom ... after all, voicemails and e-mails pile up wherever you go, and your
beeper and cell phone are just waiting to go off at the most inopportune times.
These are the realities of IT life. Technology has become an integral part of most business
operations. Any project or systems management process having a disruptive impact upon
business operations cannot be implemented during normal business hours, frequently
creating long days, and even longer work weeks. A three day weekend may be a holiday
for most, but it is too often a rollout or upgrade opportunity for IT.
These constant and conflicting demands create a very stressful, hectic work environment for the
IT manager and his/her team. This can lead to a staff burnout, creating a negative atmosphere
vulnerable to lowered performance and productivity.
WATCH FOR THE SIGNS:
While your staff may speak up when workplace demands become too overwhelming, you cannot
just wait for them to bring the matter to your attention. They may not want to complain, or by the
time they speak up, it may be too late - the problem and its consequences may have already
taken hold.
As a manager, you must monitor all aspects of staff morale and performance, and learn how to
detect the warning signs before those signs are readily visible to anyone else who cares to see
them.
The Warning Sign Checklist:
Attendance - sudden, chronic lateness or an increase in absenteeism.
Productivity - decreases in the quantity of work accomplished over a period of time.
Performance - decreases in the quality of work accomplished over a period of time.
Attention to Detail - small, but noticeable mistakes and omissions in work completed,
marked by their unusual nature (i.e. things that have been done correctly in past are
now slipping through the cracks).
Procrastination - a fixation on minor details and routine tasks at the expense of riskier,
more complex activities.
Relationships - a reduction in socialization and team activities, marked by conflicts,

arguments and withdrawal from group activities.
Attitude - a negative shift in attitude towards the job, the organization, end-users and
co-workers, marked by anger sarcasm, irritability, fatigue, sensitivity to criticism, or
indifference.
Perceptions - a general feeling that IT is unappreciated and taken advantage of by the

organization as a whole.
BURNOUT MANAGEMENT:
Once you have identified the signs of a burnout problem, what can you do to prevent a full
blown burnout disaster? Burnout can occur on a "team" or individual level. Team burnout
occurs as the overburdened group reacts collectively to difficult projects and work environments.
Individual burnout can be brought about by underlying emotional or physical problems. These
situations should be escalated immediately to management and human resources. When
individual or team burnout appears "environmental", you should look to the working source of the
problem.....
Burnout is most often the result of a unusually heavy workload, exacerbated by short
timelines, long work hours, demanding end-users, and negative perceptions of IT as an
organizational entity.
In consideration of these issues, the following tips and tricks can be used to relieve the pressure
and hopefully shift the workplace dynamic ...
1. Seek out every possible process, procedure and tool for efficiency and productivity.
2. Set realistic schedules for projects and other activities - allow for the unexpected problem
that may cause delays.
3. Let your staff have some downtime - do not schedule work for every weekend, and
encourage staff to go home "on time" as often as possible.
4. Be visible - show your staff that you are in the boat along with them. Even if you cannot
contribute to an installation on a technical basis, be there to provide moral support.
5. Set aside "cool-down" periods after every major project - allowing staff to regroup and
savor the accomplishment.
6. Consider the consequences and impact on staff before making promises and
commitments. And be prepared to quantify and communicate those consequences. At
the very least, said consequences can be used as a bargaining chip in service and
project negotiations.
7. Take advantage of remote access technologies for off-hours support, and to allow for
flexible work schedules and telecommuting.
8. Rotate on-call schedules as often as possible. And "not on call" should mean just that ...
give your staff some time to clear their heads and refresh their perspectives.
9. Take every opportunity to publicize IT successes, making sure management and endusers are aware of the contribution that IT makes to the organization. These facts can be
very useful to bolster any effort to minimize demands for unreasonable support.
10. Create and enforce realistic Service Level Agreements.
11. Maintain proper systems documentation and problem tracking databases to leverage
prior experiences and facilitate problem resolution. This will allow a greater number of
staff members to share off-hours support duties.
12. Set limits on off-hours contacts, and get management concurrence to enforce those
limits. Not every problem is an emergency and certain boundaries must be accepted.
13. Recognize and reward long work hours whenever possible. Depending upon your
circumstances, you may be able to offer additional vacation time, personal time, allow
staff to attend free seminars or trade shows (frequently offered by vendors), or just have
a team party.
Ideas into Action:
The following tools will help you to create an effective working environment for your IT
operation.....
ITtoolkit.com Quick Tools:

The Staff Burnout Assessment
Project Skills Evaluator
IT Mission Statement Template
MORE ABOUT IT:
The Project Skills Scorecard is used to analyze project skills readiness. Does your team
have the skills needed to complete the current project?
Enter basic project information in the spaces provided.
Describe the specific skills required in the spaces provided.
For each skill, rank according to priority (high, medium or low).
For each skill, rank current internal capability (high, medium or low).
Your "Skill Alignment Score" will be automatically calculated
Project "execution" begins with a plan, but project "planning" begins with a vision. In
order to have a successful project, you have to have a clear view of the goals and results
to be accomplished. You have to understand the "who, what, when, where, how and
why" of your project. THE PROJECT PLANNING ROADMAP, from ITtoolkit.com,
is a simple, straightforward planning tool, showing you how to define and document
these critical elements, and helping you build a "planning framework" for all your
projects.
THE PROJECT PLANNING ROADMAP uses a simple "question and answer" format
to help you ...
Describe your project.
Identify key project stakeholders.
Evaluate management support.
Define project goals, deliverables, and scope.
Define acceptance and success criteria.
Establish scheduling, milestone and structural (phase and sub-phase) parameters.
Quantify the work effort required to plan, execute and complete the project.
And much more......
HOW TO GET YOUR PROJECTS ON THE FAST TRACK

Fast tracking is a management technique used to ensure that projects are completed
within the shortest time possible. When projects are "fast-tracked", it usually indicates
that tasks have been arranged to take advantage of non-dependent activities that can
occur simultaneously, thus shortening the overall project timeline.
But, there is more to fast-tracking than the sequencing of tasks and activities.
Is fast-tracking appropriate for you and your current project?
Before you can safely fast-track a project, you must first address a few assumptions...
You must have a realistic schedule, with all tasks and activities properly identified.
You must be aware of all task dependencies (knowing which tasks must end before
others can begin).
You must have a solid grasp on project requirements, objectives and priorities.
You must have a good relationship with your end-users and management.
You must have a good process for tracking progress and managing risks and
problems.
Once you can meet all these assumptions, you will then have to address your needs ....
why do you need to fast-track the project?
Fast-tracking can be appropriate under a number of circumstances and conditions. It is
important to note that fast-tracking has its risks ... most notably, a project that is on the
fast track can be harder to manage because of all the simultaneous activity. In addition, if
and when problems occur, the negative impact can be more serious considering the extent
of activity underway. So, fast-tracking should be carefully considered.
Fast Track Circumstances: when to fast-track.....
The project has to be completed within the shortest time possible to meet required
business needs and objectives.
The project has to be completed sooner than expected due to changing

circumstances.
The project is behind schedule and the remaining tasks have to be streamlined to
make up for lost time.
The project is in trouble, and fast-tracking is needed to minimize further losses

and damage.
When faced with the need to fast-track a project, the first thought may be to add
resources, or even more likely, to put in more work hours. But these options are not
always productive or viable.
The application of additional staff resources, which may not even be a possibility, is often
not a solution. Under some project circumstances, no matter how many resources you
add, certain tasks can only be completed by a finite number of resources. Additional
resources may only cause confusion, and in fact, may impede, rather that promote
progress.
Overtime is also a tricky proposition. While additional work hours may shorten an
otherwise lagging schedule, excessive overtime may backfire if staff burn-out sets in.
Considering these issues, fast-tracking may be best used as a strategic weapon, where you
first look to the project schedule and then the project itself to ensure that all efficiencies
are being met.
The Fast-Track Process
Step One: Understand your Goals & Capabilities
Why do you need to fast-track?
Are you looking for project efficiencies or to solve problems?
Do you have the skills and resources needed to properly manage this project once
it is on the fast-track.
Step Two: Examine the Project Schedule
Identify hard dependencies (those tasks which have a "finish - start" relationship
that cannot be changed).
Identify soft dependencies (those tasks which can possibly be modified to remove
dependencies).
Identify concurrent tasks (tasks having no dependencies and can occur

simultaneously). This is the key to fast tracking.
Step Three: Re-work the Project Timeline
Having identified concurrent tasks, create a schedule that allows these tasks to be
completed in the shortest time possible.
Break down soft dependencies into task sub-sets, removing dependencies to

shorten the project timeline.
Focus on the remaining hard dependencies, assigning rotating staff, working in

shifts, to allow more time to be spent on each task, thus shortening the overall
timeline.
Step Four: Examine Alternatives
Can additional resources be added, and to which project tasks can those resources
best be applied?
Can additional work hours (overtime) be authorized, and how should those
additional hours be applied?
Can the scope of the project be changed to shorten the project schedule?
Can deliverables functionality be reduced to shorten the project schedule?
Can the project be outsourced in order to shorten the project schedule?
Step Five: Weigh Alternatives

As you examine and consider these fast-track alternatives, you need to weigh each
alternative against....
Time: How much time do you need to save?
Gain: What benefits will be realized from fast-tracking?
Costs: What costs will be incurred from fast-tracking?
Impact: What will the impact be on staff, and on other projects already
underway?
Step 6: Seek Consensus

Before you fast-track a project, you should ensure that your analysis is complete, and that
you have the buy-in of those who would be impacted by the fast-track decision, including
staff and end-users. You may need to fast-track without total agreement, but cooperation
will be greatly enhanced if all points of view are considered.
Step 7: Monitor Progress and Track Problems
Once in fast-track mode, effective issues tracking and problem management becomes
essential. By definition, a fast-track project will be proceeding at an aggressive pace, and
there will be alot of activity going on at once. The luxury of finishing one task and then
moving on the next will be gone, so the ability to track multiple tasks and manage issues
and problems will be critical to success.
Conclusions:
In all likelihood, every project customer wants their project completed as quickly as
possible. In and of itself, this is not a reason to fast-track. Depending upon the type of
project, the experience of the project team and the results desired, fast-tracking may not
be an option. Sometimes a project must proceed along a timeline that cannot be
shortened, despite the best intentions. However, when used with discretion and
efficiency, fast-tracking can be a productive means for responding to changing business
needs and project circumstances.
WORKBOOK PRODUCTS:
Jumpstart your projects with a timely definition of requirements and deliverables, as you
take positive steps towards success with a careful analysis of key planning variables.
Using the pre-formatted roadmap template, you will quickly define and document a
complete project vision, getting your projects off on the right track.
Plan communications strategies, and manage related activities, including meetings,
reporting and more.

The right set of project management standards will help you to achieve on time, on target
results for each and every project. Learn how to plan, create and implement your own set
of standards and best practices.
To take advantage of the valuable lessons "hidden within", every project should conclude
with a review of deliverables, procedures and participation. This Kit provides a fast path
to meaningful post project reviews.
HOW TO ANALYZE AND CONTROL PROJECT RISKS
The risk management process begins with identification to assess a project for potential risks
that could threaten the project process itself, or the outcome. But identification is only the
beginning....
Once probable risks are identified, they must then be assessed to determine the level
of impact will there be a negative impact, and how serious will it be?
If the impact is serious, that raises another question . is the negative impact so
serious as to warrant further action?
This is a critical juncture in the risk management process. Every effort to control and mitigate risk
has a price - in terms of time, money or resources. Before any action is taken to accept, avoid, or
mitigate risk, these costs must be carefully considered.
Once you have identified and categorized probable risks to your project, you can turn to the
assessment phase of the risk management process.
The goal of the risk assessment phase is twofold:
To determine the likely impact of probable risk.
To evaluate that impact in order to determine the need for further action.
Determine the Impact:

Now is the time to take out that crystal ball. In order to properly manage any threats to project
success, you must first anticipate and predict the likely impact of probable risk. There is no magic
formula for this prediction, just knowledge, common sense and experience.
The starting point for this type of risk assessment is predicated upon the existence and quality of
project scope and goals. If you have clearly identified your project goals and priorities, then you
will be able to use that knowledge to assess the impact and consequences of any probable
project risks. For example, if you view probable risk and likely impact in context of overall project
priorities, you will be in a better position to evaluate the need for targeted action.
To that end, with your identified risks in hand, you will now need to consider the following
types of questions.....
Can this risk affect the quality of my product or project end-result?
Can this risk affect project budgets and costs?
Can this risk affect the project schedule?
Can this risk affect the project planning and management process?
Can this risk affect the stability of project work environment?
For each "yes", you can then proceed to the next series of questions ....
Does this risk pose a sufficient threat to my project so that further action is warranted?
THE ANSWER = NO
If the answer is "no", then the results of that analysis should be properly documented, thus
declaring that no further action is warranted. Remember that the goal of risk management is not
just to avoid risk, but to also apply logic and reality to any decisions and strategies for dealing
with risk. If, at this point, you can acknowledge risks, and logically decide to take no further
action, your goals in risk management will be realized.
THE ANSWER = YES
However, if the answer is once again "yes", thus acknowledging the need for further action, then
continued assessment should proceed.
Once you acknowledge the possibility of impact, and the need for further action, you will then
need to look at the issue of consequences. For example, you may know that a delay in network
card delivery could impact a desktop installation project, but how will that delay affect the overall
project.... will that one delay affect the entire schedule, or can other parallel activities help to
make up for that lost time? The answers to these types of questions will help you to pinpoint the
likely consequences of a given risk.
TAKE ACTION ...
With this information in hand, you can then evaluate the need for mitigation and control.
Determine the need for mitigation and control:
At this point, you may have taken steps to acknowledge the potential impact of risks, but
awareness may not be enough. While you may choose to accept one or more types of risks, you
may not be willing, or able, to withstand others. And, considering the time, effort and potential
cost of risk control strategies, any such effort should be expended wisely.
As an example ... weighing the options

Based on an analysis of probable risks, you may decide that you can withstand additional
project expenses, but not schedule delays. As a result, you can focus your mitigation and
control efforts onto timing risks, knowing that you could absorb certain increases in
expenditures. Or, if your project schedule is aggressive, with limited time for risk analysis
and control, you may decide to deal only with the most serious types of risks, taking your
chances with others.
After completion of the risk assessment process, you will be prepared to tackle the next step ...
the formation of specific strategies for risk management and control. These strategies can include
acceptance, avoidance or mitigation.
Acceptance:
Where you acknowledge the risk, but decide that any actions to avoid or mitigate the risk can be
too costly or time consuming. Or, it may just be possible that the risk cannot be avoided or
mitigated in any meaningful way, and the benefits of the project far outweigh the risks.
Avoidance:
Where you take steps to eliminate the risk in entirety. Depending upon the circumstances, you
may need to change project scope, modify project plans, hire additional resources, or adopt
different technical solutions. Avoidance can be costly, but it may be the only way to achieve
project deliverables.
Mitigation:
Where you seek to minimize the potential impact of any given risk through the analysis and
consideration of alternative solutions. In essence, this is a combination of acceptance and
avoidance. You can alter plans and schedules, and take specific actions to minimize the chance
that a risk will occur. And, you can also develop alternate plans to be enacted should the risk
actually occur.... "i.e. if this happens, I will do that, but until then, I will stick with the original plan".
In other words, you can be prepared in either event. While mitigating strategies provide the best
of both worlds, that benefit cannot be realized without some expense in terms of time, equipment
and staff resources.
CONCLUSIONS.....
Whether you choose to accept, avoid or mitigate risks, you will need to carefully evaluate every
risk presented, and make considered choices based on specific business needs, project
circumstances, likely costs, and available time and staff resources. There is no one formula for
risk management, but risk identification, assessment and control is a key element of successful
project planning.
Ideas into Action: The Project Risks Scorecard (Quick Tool)
MORE ABOUT PROJECT RISK MANAGEMENT:
An all-in-one planning solution designed to produce risk management "process" deliverables for
all your projects. The Kit contains information, advice, planning forms, and pre-formatted "Plan"
templates.
Practical perspectives on project risk management, showing you how to minimize and
mitigate project risks with the use of a few simple, well-placed strategies.
The Risk Assessment and Response Template to help you identify, analyze and
control project risks.
The Risk Status Template to help you track risk progress throughout the course of the
project.
The Risk Management Policy Template to help you document your own set of risk
management policies and procedures.
HOW TO TEST TECHNOLOGY DELIVERABLES

Testing is essential to the success of any technology project. Despite the best technical plans and
designs, problems, errors and bugs do occur. And, in the interests of all concerned, all negative
impact issues should be uncovered before a project deliverable becomes "a production
environment". A well planned testing process will serve this purpose.
In the IT environment, the "testing" process fills many needs depending upon the nature of the
project at hand. On a generic level, testing serves several key goals:
To verify that the project deliverable functions according to design.
To verify that all identified operational requirements have been met.
To uncover problems, bugs and errors.
But these goals are just the tip of the iceberg. Considering the varied nature of technology
projects, testing can be used in various ways, and at varying points in the overall project process.
As such, testing needs will change according to project timelines and circumstances, depending
upon whether the project involves coding, network design, physical hardware installation, "off-theshelf" software installation, and/or documentation development. As such, within any project
environment, you may need to address any or all of the following testing issues:
1. Software code testing.
2. Hardware and/or software installation testing (to validate installation procedures).
3. Hardware and/or software operational testing.
4. Documentation testing.
5. Support procedures testing.
6. Training materials testing.
As you assess and plan your testing process for any given project, three key questions must be
addressed:
What are your testing goals and objectives?
What testing methods will be used?
How will your tests be planned and executed?
What are your testing goals and objectives?

In order to set effective goals and objectives for any testing process, you must have a solid grasp
on project needs and circumstances. Testing must be sized and scaled to meet primary project
needs considering business objectives and technical requirements, as well as available time,
resources and budgets. As such, the following issues and questions should be addressed as
testing needs are analyzed and planned....
Question 1: What are you trying to test?
Hardware
"Off-the-shelf" software
Custom application code
Workflows
Documentation
Installation procedures
Question 2: What are your testing objectives?
To identify potential problems, bugs, errors and incompatibilities.
To validate operational functionality.
To verify design and/or coding quality.
To validate functional specifications.
To validate usability.
To validate "proof of concept" (i.e. via a pilot installation).
To verify performance and capacity.
To simulate "real-world" operational circumstances or to "quick" test for basic functionality

and operational viability.
Question 3: What are your testing priorities considering the following variables.?
Intended project purpose. (How will the project deliverable(s) be used within the
business?) Visible and valuable projects demand more detailed testing.
Features and functionality. (What are the most important features and functions?)
When time is short, testing can be limited to the most important and valuable deliverable
elements.
Technical complexity. (What elements require the most testing due to the degree of
technical complexity?) More complex technical solutions will probably involve more
extensive testing.
The degree of risk involved should problems occurs in the production

environment. Testing should be designed to mitigate and minimize risks.
Financial costs of testing versus the financial costs of problems. At some point, the cost
of extensive testing may outweigh the costs of production problems.
What testing methods will be used?

CHOOSING TESTING METHODS
Once you have identified your testing needs and

priorities, you will need to consider the available testing
methodologies. Once again, accepted methodologies will
vary based on available tools and resources, as well as
project needs and circumstances.
Expected benefits.
Considering these varying factors, any given testing

process may include one or more of the following
elements:
Available time, skills and resources.
Cost factors.
Applicability to project deliverables and

needs.
Automated Testing: Tests conducted with the use of software tools which complete a
series of pre-defined, automated tests.
Manual Testing: Tests conducted through manual steps and scripts (human
intervention).
Functional Testing: To validate operational functional and features specifications.
Compatibility Testing: To validate compatibility with other existing systems.
Integration Testing: To test individual components to determine whether they function

as a unit (i.e. share data).
Performance Testing: To validate compliance with performance requirements and

specifications. Performance testing requires load simulation to verify performance under
"production-like" circumstances.
Stress Testing: To validate the operational limits of a project deliverable according to

load and capacity (i.e. how much can this system handle in terms of simultaneous users
and transactions?), requiring load simulation.
Regression Testing: To re-test a project deliverable after changes have been made to
verify that problems have been solved, and to ensure that new problems have not been
introduced.
Conformance Testing: To validate whether the project deliverable conforms to

documented requirements and specifications.
Workflow Testing: To validate deliverables functionality and viability using actual enduser workflows (real-world procedures and circumstances) as a basis for testing.
Ad-Hoc Testing: To validate deliverables functionality and viability using random,

unscripted testing by end-users (i.e. to try to uncover the unexpected).
Acceptance Testing: To verify whether the project deliverable meets pre-defined project
acceptance criteria. Acceptance testing should take place only after initial testing is
completed, and all technical problems and errors have been identified and resolved.
How will your tests be planned and executed?

There are three primary deliverables that can apply to any testing process..
The Test Plan: The Test Plan document lays out a roadmap for the testing process,
specifying overall goals, scope, test assumptions, logistics, risks, tasks and resource
assignments.
The Test Specification: The Test Specifications document details the tests to be
performed according to type, purpose, expected result, inclusions, exclusions and
methodologies.
The Test Script: The Test Script document provides a specific set of instructions to be
executed for each element of the testing process. Test scripts can be automated (for use
by software testing tools) or manual (to be executed by end-users or IT personnel as
appropriate). In addition, test scripts should always define a clear process for recording
results.
Test Planning Step by Step:

1. Identify your testing requirements.
2. Set your testing goals and objectives.
3. Select your testing methodologies.
4. Create your Test Plan and obtain approvals as needed.
5. Create your Test Specifications and obtain approvals as needed.
6. Build your test environment (hardware, software, infrastructure, etc).
7. Create your Test Scripts and obtain approvals as needed.
8. Schedule your test and obtain approvals as needed.
9. Notify all participants.
10. Conduct your test and record all results.
11. Analyze results and apply the lessons learned to resolve identified problems and related
operational issues.
Conclusions:
While testing can take considerable time and effort, that time will be well spent if serious
problems and issues are uncovered. Effective testing should be viewed as an essential project
"insurance plan", designed for many purposes, from technical problem resolution to proof of
concept validation. Through testing you may find that your technical solution works, but fails to fill
the expected operational need. As such, testing fills an overall role of project validation and
quality assurance. And, to realize these benefits, testing must be planned, coordinated and
tailored to meet the needs of the project at hand.
Ideas into Action: The Test Plan Checklist (Quick Tool)
MORE ABOUT IT MANAGEMENT....

PROJECT-SPEAK: DELIVERABLES
On the surface, "deliverable" looks like just another fancy word for the product or process created
as a result of a project. Until you look deeper.
This second entry in our "project-speak" series examines the role that deliverables play in the
project process - from initiation to closure:
Deliverables must be identified.
Deliverables must be specified.
Deliverables must be designed.
Deliverables must be scheduled.
Deliverables must be produced.
Deliverables must be tested and verified.
Deliverables must be accepted and approved.
Identifying Deliverables: Within any project environment, deliverables will likely fall into three
categories:
Project Deliverables
Planning Deliverables
Activity Deliverables
Project Deliverables:
The tangible products, services or plans delivered as an outcome to a project, designed to meet
identified goals and objectives. Depending on the needs of the project, project deliverables can
be both "physical" and "logical" in nature. For any given initiative, multiple "project deliverables
will likely be produced, at various points in the project process.
Examples of Physical Project
Deliverables
Examples of Logical Project

Deliverables
Hardware
Workflow
Software
Performance Improvements
Training Materials
Problem Solutions
Documentation
Recommendations
Within the project process, project deliverables are part of the quartet of key project definitions.
GOALS: Explain the need for the
deliverables according to purpose,
value and benefits.
REQUIREMENTS: Form the basis for

deliverables usage, form and function.
DELIVERABLES: The physical and/or

SCOPE: The work required to
logical manifestation of goals and
produce the planned deliverables.
requirements.
Project deliverables can also be further categorized according to longevity and timing. Project
deliverables can be interim (subject to change or incorporation into the whole) or final, and may
be produced at any stage in the project process:
At project start-up.
By milestone.
On the critical path.
By phase.
By task.
At project acceptance and closure.
Planning Deliverables:
Planning deliverables are produced as part of the project management process, and are the
means by which projects are planned and executed. Planning deliverables document and record
the strategies, plans, policies and procedures to be used and followed as the project is
completed. As the list below illustrates, planning deliverables are comprised by the documents,
information, and data needed to manage the project itself:
Project Proposal
Business Case
Statement of Work
Project Plans
Resource Matrix
Budget
Risk Plan
Communications Plan
Quality Assurance Plan
Transition Plan
Activity Deliverables:
Activity deliverables are at the most granular level of the deliverables spectrum, produced as a
result of a specific project activity. Activity deliverables are normally administrative in nature,
reflective of the project process itself (i.e. the activities needed to support the project). As such,
activity deliverables can include the following:
Status Reports
Meeting Agendas
Meeting Minutes
Purchase Orders
Timesheets
Contact Lists
Specifying Deliverables: Deliverables specification is the process by which deliverables are

described and documented in order to:
Commit "concept" to paper.
Form a basis for review and negotiation.
Confirm requirements.
Clearly set expectations.
Secure consensus and acceptance.
To meet these objectives, deliverables must be described in sufficient detail so that actual results
are not left to the imagination. Consider the following example ... which description tells a better
story?
The Project: Desktop Inventory Project
Deliverables Description #1: Inventory report and recommendation.
Deliverables Description #2: Inventory report documenting the current location, serial
number and hardware configuration of all desktop computers, monitors, printers and
peripherals, along with a recommended solution for physical asset tagging and inventory
control.
Planning and Managing Deliverables: Projects are all about results whether those results
represent the final outcome, or an interim product or process needed to produce the final
outcome. As such, deliverables have to be considered at every stage of the project process
according to type, timing and purpose:
Project Stage:
Deliverables Type, Timing and Purpose:
Project Selection
Project deliverables are proposed and analyzed for feasibility.

This analysis forms the basis for the project "go /no-go" decision.
Project Initiation
Project deliverables are specified and approved to ensure that

requirements are met and all stakeholders share a common
vision. Planning deliverables are also specified to estimate
project duration, effort and costs.
Project Planning
All deliverables (project, planning and activity) are structured and

scheduled to fit into a project timeline, allowing for the allocation
of project resources.
Project Execution
All deliverables are produced according to plan, with appropriate

oversight applied (progress measurement, testing and change
control).
Project Closure
Final project deliverables are produced and accepted after

appropriate testing and training. In addition, all deliverables are
reviewed as part of the "lessons learned" process.
Questions to Consider in Deliverables Planning:

Project Deliverables Analysis:
How will the deliverable be used?
The process by which project

deliverables are planned.
Who will use it?
Should you build or buy?
How much will it cost?
How will it be tested?
How will it be maintained?
Are there any alternatives?
How will the deliverable be produced?
When is it due?
Is it an interim deliverable or a final

deliverable?
What planning deliverables are required to
Planning Deliverables Analysis:
The process by which planning

Activity Deliverables Analysis:

The process by which activity
complete this project?
How much time will it take to produce each

required deliverable?
When is each due?
What formats will be used?
Who will be responsible?
Who must accept and approve?
How will each deliverable be updated and

maintained?
What activity deliverables are required in this

project?
How will activity deliverables be produced?
Who is responsible?
What formats will be used?
How often will activity deliverables be required?
Ideas into Action: The Acceptance Criteria Worksheet (Quick Tools)

WORKBOOK PRODUCTS:
more.
and best practices.
PROJECT-SPEAK: MILESTONES
Projects are a complex confluence of distributed tasks and deliverables, doled out to project team
members and related participants. This work distribution is essential to timely project completion.
Projects cannot be completed at "30,000 feet". You have to be on the ground. To deliver timely
results, tasks and deliverables must be broken down into "workable efficiencies" . i.e. small,
manageable work components. But, while this break-down facilities project completion, it
complicates progress measurement. It is difficult, if not impossible, to get a sense of "overall
status" by looking solely at individual tasks and assignments. To judge progress, you have to look
at the project at a higher level of goals and accomplishments. This is where the "milestone"
matters.
What are project milestones?
Project milestones are "how are we doing?" thresholds, indicating whether a project is on track
to finish as expected, planned and required. Specific milestones will vary by project, but in
general, milestones can be defined as the set of accomplishments, results, deliverables and
events that can be used to measure project progress.
As such, milestones serve three important goals:
1. Milestones provide "measurements", showing that tangible progress has been made.
2. Milestones provide "validation", allowing you to move on to the "next step" in the project if
the milestone is met, or enabling corrective action if the milestone is not met.
3. Milestones provide "short term work targets", to motivate project team members.
While specifics will vary according to project type and circumstances (considering duration, scope
and complexity), identified milestones typically include any or all of the following elements:
MILESTONE TYPE:
MILESTONE PURPOSE:
Proposals and
Recommendations
Providing a basis for approvals and decisions.
Approvals and Decisions
Providing acceptance and authority to proceed.
Deliverables (Incremental
deliverables that stand on
their own, or deliverables
sub-sets)
Providing progress measurement, evaluation opportunity

and "proof of deliverables" verification.
Events (Significant project

events such as a kick-offs,
pilots, or end of a phase or
sub-project)
Indicating progress along the project timeline.
MILESTONE MANAGEMENT
What purpose will milestones serve in your project?
Milestone management begins with identification. Milestone identification occurs in the initial
planning phases, as the project is structured and defined. As the milestone identification process
begins, specific levels must be considered:
Milestone Levels
Individual Milestones: Perspective: The individual project staffer. Relating to individual

work assignments made to project team members. Purpose: To provide individual staff
members with an opportunity (an obligation) to measure and report assigned "work"
progress at an "accomplishments" level (linking individual tasks to overall project results.)
Team Milestones: Perspective: The project team. Relating to team assignments and
responsibilities. Purpose: To provide one or more project teams with an opportunity (and
obligation) to report on assigned work and accomplishments at an "accomplishments"
level (linking team responsibilities to overall project results.)
Major Milestones: Perspective: The "Project". Relating to interim results and progress.
Purpose: To track project progress, deliverables and events at the "big picture" level.
Depending on specific circumstances, milestones can be identified and tracked at each of these
levels as needed to meet project goals. Note: If you need to motivate project staff, individual
and/or team milestone management is essential.
Milestone Specification
Milestones provide an opportunity to track and manage projects according to a timeline of
accomplishments in addition to the necessary, but more mundane, work hour allocations and
assignments. Milestone identification and reporting is essential to "management support". To
maintain appropriate support for your project, you must be able to translate progress from
baseline percentages into tangible accomplishments. For example, "we are 50% complete" pales
in comparison to a list of "milestones met". For that reason, milestones must be described in
meaningful terms that meet all of the following elements:
Milestone
Description
To identify and describe the milestone in relevant

terms. The description must match milestone purpose
as "measurement", "checkpoint" or "work target".
Milestone Date
To specify the milestone "due date". (i.e. the specific

point in time when milestone must be met.)
Milestone Results
To specify the expected result and meaning. (i.e. what

will happen next once the milestone is met?)
Milestone Risks
To identify any risks involved if and when the milestone

is not met as needed and expected.
To identify project milestones, the project must be broken down into a structured timeline of
logical "checkpoints" (major task sets, phases or other logical phases). These checkpoints
determine the flow of the project, and milestones can be inserted into this flow at strategic points
based on "needs and purpose". As such, for identification purposes, each potential milestone can
be viewed from the following perspectives:
Timing: Checkpoint Assignment (Milestone Date)
Level: Individual, Team or Major Milestone
Type: Proposal/Recommendation, Approval/Decision, Deliverable, or Event
Purpose: Measurement, Validation or Work Target
Milestone Tracking
Once milestones are identified and documented as part of the project plan and schedule, the
tracking process will begin. Milestones should be identified and established at sufficient points in
the project timeline to allow for effective monitoring. If milestones are set only at the end of a
phase, mid-point problems may be missed, and it may be too late to take corrective actions.
Individual and team milestones can be used to feed major milestones, acting as pre-cursors to
monitor and predict milestone progress. It stands to reason that if individual and/or team
milestones are not being met, major milestones will likely share the same fate.
If milestones are being met, or are ahead of schedule, the project can proceed as planned. If the
milestones are not being met, then certain defining questions must be addressed:
Which milestones are not being met?
What are the likely reasons for any "milestone mishaps"?
What can be done to correct or mitigate these issues and problems?
CONCLUSIONS......
Naturally, corrective actions will vary based on the nature of the problem or delay, but one thing is
clear - without milestones you are left with two options. try to track overall progress based on
individual task assignments, or wait until your scheduled project completion date to find out if your
project is actually "complete". Neither option makes much sense. With milestones you can
manage your projects for results and goals. As each milestone date approaches, you will be
handed a true sense of the project in terms of the schedule, goals, results and next steps. You
will either find yourself on the right track, or off target. In either event, you will know where you
stand and can react accordingly.
The WBS Building Blocks Worksheet (Quick Tool)
WORKBOOK PRODUCTS: New and Improved!
more.
and best practices.
HOW TO TAKE AN ACTIVE ROLE IN YOUR OWN PERFORMANCE REVIEW

The performance review process can be a very uncomfortable experience, even for the most selfconfident. It is not easy to be judged by others, particularly when that judgment affects career and
livelihood.
At first glance, it may seem that performance reviews are a one way street .... the manager talks
and you listen. But the performance evaluation process does not have to be a passive activity.
You can be an active participant, and even help to influence the outcome.
FOUR STEPS TO PERFORMANCE REVIEW PARTICIPATION:
Familiarize yourself with internal performance appraisal policies and procedures.
Keep accurate records of your ongoing performance.
Evaluate your own performance objectively and fairly.
Acknowledge problems and anticipate objections.
Step One: Performance Policies & Procedures

In order to prepare for any performance review, it is important to review and understand all
internal policies and procedures relating to performance appraisal. Be sure you can answer
most, if not all of the following questions....
How is performance measured and rated .... i.e. on a performance scale, or a ranking
compared to others?
How often is performance evaluated?
Do peers and other management personnel participate in the reviewing process?
How do performance reviews affect salary increases, work assignments and promotions?
How can unfair reviews be challenged?
Step Two: Track Performance

In order assess the validity of your performance review, and also respond to any issues, you will
need to be track the quality of your own performance. This is where facts and figures are
important. You should keep accurate records, perhaps in a log or calendar, of all your efforts and
contributions, which can include any number of the following:
Record all tangible achievements and accomplishments for special projects and work
assignments.
Consider the timeliness and quality of ongoing work responsibilities.
Save memos, e-mails, and all other documents that reflect your ideas, quality of work
and degree of dedication.
Keep copies of any complimentary memos, e-mails or letters from peers, end-users,
customers or external service providers.
Save certifications, agendas, or other acknowledgements of training classes,

educational conferences and seminars that you may have attended, including any you
attend on your own time.
Step Three: Evaluate Performance

As difficult as it may be to evaluate someone elses performance, it is even harder to objectively
evaluate the quality of your own work. However, if you are to be prepared for an upcoming
performance review, it is best to view your performance history from a perspective other than
your own .... i.e. as your manager would view it.
As you take this view, consider the following questions....
How well have you met your documented performance objectives? While the quality of
individual work may be exceptional, it must also be in alignment with established
performance objectives. Please note that you should always keep an eye on
documented performance objectives, and have them revised if the work
assigned to you appears in conflict.
Have you gone above and beyond in terms of additional projects or added
responsibilities?
How well have you handled the unexpected, including problems, or changes in roles
and responsibilities?
How has your contribution compared with others? This may be very difficult to assess,
but bear in mind that most managers do have to consider this.
Step Four: Handling Problems and Objections

We all make mistakes, and you should be prepared to acknowledge any performance problems
that do occur. You do not want to appear defensive, but you need to ensure that problems are
viewed in proper context, in consideration of your overall contribution and working conditions. It is
best to track and document problems as they occur. Rest assured that your manager will
probably do the same.
And when addressing performance deficiencies, be sure to stress the positive aspects ...
i.e. how you may have learned from your mistakes, and how you have put that knowledge
into practice. In addition, be sure to ask for feedback on how you may further improve
performance or advance position. Document these suggestions and try to act upon them.
That will be your first step in preparing for your next review.
CONCLUSIONS.....
Your active participation in the performance appraisal process is a positive step towards effective
career management. The benefits may not be realized immediately, but your career is an
ongoing, long term process. At a minimum, you will demonstrate that career and quality is
important to you, and that fact may very well influence future assignments and opportunities.
Related Reading ...... Career Planning Articles
What impact does "industry" have upon the IT professional? Does the IT job at a law
firm offer the same challenges and opportunities as an IT job at a bank? read
more....
Does your resume present the best possible picture? To create a resume that stands
out in the crowd, present your skills through the prism of business accomplishment.
read more....
WORKBOOK PRODUCTS:
more.
and best practices.
VIRTUAL PROJECT MANAGEMENT: HOW TO LEAD THE CONFERENCE

CALL
As a manager, you will probably be called upon to lead the occasional (or perhaps frequent)
telephone conference call. While these conference calls will never fully replace the need for
"face-to-face" meeting, they are a necessary tool for communication and decision making in a
faced paced IT project environment.
We may all be more comfortable within the setting of a traditional meeting, where visual clues can
help us charter a course through conflict and internal politics, but if managed properly, the
conference call can also be an effective form of project communication.
BE PREPARED
Preparation is the key to managing any productive meeting, but thorough preparation is vital to
the success of any conference call. The road to preparation begins with the agenda. In addition to
ensuring the very quality and structure of agenda itself, the conference call leader must also have
the agenda ready in sufficient time for advance distribution. In a conference call situation, you
cannot simply dash into the conference room at the last minute, agenda copies in hand, fresh off
the copier or printer. You must set aside sufficient time to place the agenda online, or to fax or email copies to all meeting participants well in advance of the meeting start time. And, to ensure
full participation and attendance, your agenda should include all vital statistics about the call:
Date
Start Time (and dont forget different time zones)
End Time
Dial-in numbers and any pass codes
Name and Phone Number of the Meeting Coordinator
You can almost guarantee that your call will get off on the wrong foot if participants lack the
correct information to join in on the meeting.
SET THE ETIQUETTE
As the leader of a conference call, it is your obligation to ensure that all participants are aware of
the expected conference call etiquette. Have you ever been part of a conference call where
effective communication is interrupted by "music on hold" or the clicking sound of a keyboard as
someone checks his or her e-mail? This can be frustrating to all parties, but with the creation of
groundrules for call participation, you can achieve a more productive, courteous and timely
meeting.
Conference call etiquette should establish the following guidelines for participation:
Call in on time, and announce yourself as you join.
Do not interrupt the call if you are late, wait for a break and then announce yourself.
No cell phones or music on hold.
Take the call in a quiet place, and put your phone on mute to block any noise when you
are not speaking.
State your name before speaking.
Be prepared for the meeting with copies of the agenda and any other relevant materials.
Be courteous to other participants, do not talk over the voices of others and be mindful of
meeting timelines.
Make your comments and questions brief, relevant, and to the point.
ASSESSING CONFERENCE CALL LOGISTICS

As you prepare to plan and lead your conference call, be mindful of the impact that physical
location can have upon call dynamics. For example, if all participants in the call are remote, then
as the leader, you are just another link in the call chain. In this configuration, all participants are
on equal footing, and you can employ one set of call management techniques.
However, project and logistical circumstances may dictate a different call configuration. As a call
leader, you may find yourself in the challenging position of having some participants in the same
location as you, while other participants are in various remote locations, tied in via phone. The
meeting leader and participants in the central location are the cog in the meeting wheel. The
remote participants are the spokes.
LINKS IN A CHAIN?
Maintaining control and momentum in a meeting where all participants are remote is a challenge
for a call leader, but at least, everyone is on equal footing. The key to success is to establish
control at the very start by reviewing the agenda, and then by sticking to it. Introduce yourself as
the leader, and allow all other participants to announce themselves. And, be sure to enforce the
rules of conference call etiquette. Always start the call on time, and conduct a roll call. Expect
some late arrivals, but do not interrupt a positive flow by interrupting the discussion for anyone
who joins in late. Instead, pick a logical break point to allow late arrivals to introduce themselves
and to officially join the call.
Beyond introductions and agendas, the success of a conference call will largely depend upon the
structure and purpose of the meeting, and your ability to manage the flow. Without the benefit of
visual clues, such as the raised eyebrow, folded arms, rolling eyes, and the occasional
exaggerated toss of a pen, a leader must rely on other indicators to keep a conference call
moving along the right path.
The key to this strategy is to know your participants and to listen. It is dangerous to assume that
silence equals agreement or understanding. You must actively ask for feedback, not from the
group, but from the individuals involved. The lack of physical interaction and solitude may cause
participants to become distracted. Some may feel awkward about jumping in with their own
comments for fear that they may interrupt someone else who has been waiting to speak. As the
call leader, it is your job to directly request feedback, structuring the call so that all voices can be
heard, polling participants as needed, and challenging others to stimulate further discussion.
Without visual clues, the leader must be able to sense disinterest or intimidation, and continually
press forward for increased participation.
THE COG AND SPOKES?
Whenever the call leader and any number of participants are in one central location, and all other
participants are in one or more remote locations, extra attention must be paid to those who are
remote. In this scenario, the call leader must battle the exclusion factor wherein remote
participants can inadvertently be made to feel alone and alienated.
As the call leader, your primary obligation is to ensure that all remote participants receive copies
of any and all meeting materials. Have all "central" participants introduce themselves, and follow
suit with all remote participants.
As the call progresses, make sure all "central" participants state their names before speaking,
and ensure that they speak loudly and clearly. If you are in a large room, and must move the
speakerphone so that someone can be heard, do not allow the person to speak while the phone
is being moved. Your attempt at consideration will be lost, as remote participants are likely to
hear little more than the phone in transit.
And, if need be, as the call leader, you need to take note of key questions and comments, and
repeat them as needed for the benefit of all participants.
Without meaning to, central meeting participants can easily make remote "spokes" feel excluded
and isolated. In the "face to face" atmosphere of the central group, it is likely that some socializing
will take place. Verbal or visual joking may occur, and remote participants cannot be part of that
on an equal footing. Be sensitive to this. As the leader, it would be unwise to prevent
socialization, even if such prevention were possible. But, you can use your leadership skills to
draw remote participants into the positive atmosphere. Take the opportunity to explain a funny
situation that may have occurred. Try to create a special bond with those who are remote. Take
some meeting preparation time to gain information about the locations of remote participants (i.e.
weather or business events). Use this information to draw remote participants into any social
elements of the conference call. Your goal is to shift the focus to remote participants from time to
time. This extra bit of attention can bring out more active and enthusiastic participation, and the
result may very well be a more productive meeting.
CONCLUSIONS
With the proper leadership, and the commitment of all players, the conference call can be a
productive, cost effective alternative to "face to face" project meetings. There may very well be
circumstances under which conference calls are inappropriate. For example, complex systems
planning and design sessions may very well mandate the sort of personal interaction that can
only take place in a single physical location.
As a project manager and meeting leader, you can assess business needs, and make the best
decisions considering meeting goals, project requirements, communications capabilities and
overall costs. But whatever the format, your ability to lead a successful meeting depends upon
the degree to which you exercise quality and care in planning, communication and the
consideration of others.
Ideas into Action: The Meeting Agenda Template (Quick Tool)
MORE ABOUT IT:

HOW TO EVALUATE MEETING SUCCESS: POST MEETING

ASSESSMENTS
Your meeting is over and it is now time to take stock....
Was the meeting a success?
Were established goals and objectives reached?
What follow-up steps remain?
Of all the steps taken to plan, prepare and hold a business meeting, the most strategic work may
very well take place after the physical meeting has ended. As a meeting leader, you must be
able to assess the results of your meeting .... to follow-up on pending action items, and to plan
better meetings in the future.
Every meeting is a process, and evaluation makes the process complete. Hopefully, your
meeting was held with a purpose, and it is now time to see whether that purpose was met.
If the purpose was not met, then you need to look carefully at the process you followed for
meeting planning and preparation. Did the meeting fail to meet its purpose because of
poor planning, a lack of preparation, bad timing, participant issues, or was the meeting
inappropriate from the start?
As you examine and evaluate these issues, you need to look at five key meeting characteristics:
Meeting Results
Meeting Process
Participation and Tone
Next Steps
Future Improvements
These characteristics form the foundation of the Post-Meeting Assessment Checklist, your tool for
meeting assessment and evaluation.
The Post-Meeting Assessment Checklist
To start your Post-Meeting Assessment, you should be prepared with basic meeting information:
meeting plans and preparation materials, logistical information (start and end time), list of invitees
and attendees, the agenda, and final meeting minutes.
Evaluating Meeting Results:
What was the purpose of the meeting? (to disseminate information, make decisions, get
feedback or some other purpose)
Was the purpose met, and to what extent? (fully, somewhat or not at all)
Were planned decisions made as required and expected?
If decisions were not made as expected, why not?
Based on the results of the meeting, was this meeting necessary and worthwhile?
Evaluating the Meeting Process:
Did the meeting start and end on time?
Was the meeting held at the right time and in the right place?
Was the correct mechanism and venue used (physical meeting, phone conference, video
conference)?
Could better results have been achieved through a different meeting mechanism?
Were any technical or logistical problems experienced?
Did all or most invitees attend?
If attendance levels were not as required and expected, what was the cause?
Were the presentation materials effective?
Were the presentation materials (including the agenda) properly prepared and distributed
in advance of the meeting?
Did the quality or quantity of presentation materials enhance or diminish overall meeting
success?
Was sufficient time allocated for the meeting?
Was the meeting too lengthy or too short?
Evaluating Participation and Tone:
Were all agenda items covered? If not, what was the reason?
Are you satisfied with the quality and quantity of meeting participation?
If participation was not as expected and as required, why not?
Did you have the right mix of attendees and participants?
Were participation roles and responsibilities communicated and clarified prior to the start
of the meeting?
Was the discussion properly controlled and managed?
Were certain individuals allowed to dominate the discussion to the detriment of others?
Did the meeting have a positive or negative tone?
If the meeting tone was negative, what was the reason, and could the negativity have
been avoided?
Did the meeting "tone" have a negative or positive impact on overall meeting success?
Evaluating Next Steps:
What next steps and action items were identified and assigned at this meeting?
Were these steps and assignments appropriate considering the original purpose of the
meeting?
Were the next steps and action items fully documented at the end of the meeting?
Did all participants leave the meeting with a clear understanding of all the next step
assignments and action items?
What procedures will be followed to ensure that assignments and next steps are properly
executed and completed?
Evaluating Improvements:
Based on your responses to the aforementioned questions, what improvements can be made to
meeting plans and preparations in the future to ensure that...
meetings are appropriate to the communications needs at hand....
goals and objectives are met...
planned decisions are made as needed....
meeting venues and mechanisms are utilized effectively (i.e. physical locations, phone
conferencing and video conferencing)...
presentation materials are appropriate and distributed on a timely basis...
meetings start and end on time, and that all agenda items are covered...
maximum attendance and participation is realized...
internal conflicts are controlled and minimized....
participants and attendees are engaged and cooperative...
meeting time is well managed....
next steps are properly identified and assigned....
Depending on the nature and visibility of the meeting itself, and your individual assessment
requirements, you may choose to conduct your meeting evaluation as a personal exercise, or as
a formal survey of meeting participants. No matter how your assessment process is conducted,
the goal is simple: to gather sufficient information to determine whether the meeting was a
success, and to identify any immediate corrective measures.
CONCLUSIONS.....
It takes a good deal of effort to plan and hold an effective meeting, and that work does not end
when the meeting is over. With the right process and complete set of questions, you can
examine meeting results with a purpose that extends well beyond the scope of any one meeting
.... to learn from experience, and to make improvements in the future.
Ideas into Action: The Meeting Agenda Template (Quick Tool)
All-in-one planning solution designed to produce communications "process" deliverables for all
your projects. The Kit contains information, advice, planning forms, and pre-formatted "Plan"
templates, including....
Ready-to-use guidelines for project communications planning, showing you how to

analyze project needs, communications requirements, technical capabilities and staffing
considerations.
The Communications Planning Checklist (in Word format).
The Meeting Planning Checklist (in Word format).
The Communications Plan Template (in Word format).
HOW TO MAKE THE MOST OF TIME MANAGEMENT

Where can I find the time?
This is not an easy question to answer. How can you be expected to find the time, when so many
of the demands against that time are out of your control ....?
The truth is, you will never find the time, you have to create the time. Not by changing the clock
or the calendar, but by balancing schedules, priorities, and responsibilities through a series of
carefully crafted tips and techniques ...
The first step in time management is to assess the extent and scope of
your problem. To gain perspective on any potential time management
problems, you can begin with an examination of the problem itself,
followed by any impact to your reputation and the perceptions of
others.
Do you have a time management problem?

Step One: Assess the scope and extent of your time management problem ....
How often are you late for meetings?
How long does it take you to return phone calls?
Is that response time considered acceptable in your organization?
How long does it take you to respond to e-mails?
Is that response time considered acceptable in your organization?
How often do you miss assignment deadlines?
How often do others (end-users or managers) have to repeatedly ask you for information
that you may have forgotten to provide?
How often do you make careless mistakes or omissions because you feel rushed and
pressured?
Is your workspace messy and cluttered?
Can you easily locate files and other information when you need them?
Step Two: Assess the impact of your current time management practices on your career and
reputation ... i.e. are time management issues affecting your ability to succeed?
Have time management problems damaged your reputation and or credibility with endusers or management (i.e. are you perceived as someone who can get the job done
when pushed, but can't manage through busy periods)?
Do you feel that alternative approaches to time management could be used to improve
your professional performance, alleviate stress or just give you more free time?
Have time management problems been a source of negative performance reviews,

impacting potential promotions or salary increases?
Are you personally satisfied with your current ability to make the most of available time?
Step Three: Draw your conclusions ...

Once you have assessed the scope, extent of any time management problem, and the resulting
impact you will be in a position to take corrective action.
STEP ONE ANALYSIS:
The results of your Step One analysis should serve to identify the scope and magnitude of any
time management problems ... do you have any time management issues and how serious are
they? If you have identified any potential problem areas, your focus should now be sharper - do
you have to work on your skills for communications management, workspace organization or task
scheduling?
STEP TWO ANALYSIS:
The results of your Step Two analysis should serve to identify the impact of any time
management problems - are any of these problems having a negative impact on your reputation
or overall job performance? Or, perhaps you are just personally dissatisfied with your own ability
to manage time.
Any negative consequence is an indicator for action - to take whatever steps (see Tips & Tricks
below) are reasonable and practical for improved time management.
THE PERCEPTIONS DISCREPANCY
But what if you analysis reveals a perceptions discrepancy, i.e. you do not see a time
management problem, but you do see a negative impact, as if a problem truly existed? There
can be several reasons for this perceptions discrepancy. Perhaps you do not take time
management as seriously as your peers and co-workers. After all, you get the job done under
extremely difficult circumstances, does it really matter if you are late for a few meetings, or if you
are never at your desk to take phone calls?
But what if the problem does not really exist, and somehow you have
earned a reputation that is not truly warranted?
In this case you may need to look for other ways to deal with the negative perceptions, perhaps
with improved visibility and communication.
Tips & Tricks for Time Management
Define and document priorities and activities - organized to create a picture by day, week
and month.
Set a specific and regular for reviewing mail, returning e-mail and voicemails, and other
administrative matters.
Eliminate desktop clutter and try to handle each piece of paper only once - act, delegate
or file.
Make notes before phone calls or meetings so that you are prepared with comments and
questions.
Learn to say no -- or, at the very least, explain the impact of the unexpected on your
schedule and other deliverables.
Beware of overly aggressive commitments - keep schedules realistic.
Account for the unexpected - schedule projects and other commitments to allow for
problems and unwelcome, yet predictable, interruptions.
Revise schedules frequently and as appropriate ... if you can't meet a deadline, its better
to let everyone know as soon as possible.
Forgive yourself for problems, delays and the occasional bout of procrastination.
Ask for help or delegate whenever possible.
MORE ABOUT TIME MANAGEMENT (AND OTHER) SKILLS.....

Soft Skills are Hard to Find
Practical perspectives on the role of soft skills in the IT profession, and in the IT
environment.
Ready to use definitions for the seven primary categories of IT soft skills ... creativity,
leadership, teamwork and more....
An easy to follow, 3 step process for this multi-faceted IT soft skills assessment.
A (7) part soft skills assessment worksheet, filled with 175+ multiple choice
questions designed to help you evaluate soft skill needs and proficiencies.
Useful guidelines to help you analyze and apply assessment results - to create your
own Soft Skills Action Plan.
HOW TO IDENTIFY PROJECT RISKS

Every project involves some degree of risk ("nothing ventured, nothing gained...."), but that risk
can be controlled with a bit of careful analysis, planning and communication. As a project
manager (or a manager dealing with projects), it is your job to anticipate project risks, and then to
devise the means for controlling those risks before they can get out of hand. This is where the
risk management process comes in.....
RISK MANAGEMENT DEFINED...
Risk is all about the three questions...what can happen? ...what could result? ...what can be
done? Risk management is based on the need to anticipate and manage the elements of risk. If
realized, risks can threaten the success of a project, both in terms of process and outcome. To
effectively manage risk, threatening events and consequences should be probabilities, not merely
possibilities.
Without a crystal ball, risk management can be a challenging process. But instead of just trying to
see into the future, we can manage risk by looking at the past. By examining prior project,
experiences you can get a better handle on risk probabilities. And if you can anticipate an event,
you should be able to weigh the consequences, and control the outcome.
A PRACTICAL PROCESS:
Although specifics may vary based on the nature and complexity of a project, an effective risk
management process will have three key components:
realistic Risk Identification
realistic Risk Analysis & Assessment
realistic Risk Response & Control
You will note the repeated use of the word realistic. This is to emphasize an important aspect of
the risk analysis process...time spent analyzing risks that are possible, but improbable, will
usually be an ineffective use of time and resources. While it is possible that a meteor will
strike the earth in the midst of any given project, it is not probable, and certainly not something
that can be realistically anticipated. This extreme example aside, it still can be said that to
achieve the most effective analysis possible, it is best to keep identified risks realistic and
probable. Overall, the goal is to develop a list of probable risks, and thus lay the foundation for
the assessment and ultimate response to those risks, whether you choose avoidance, mitigation
or acceptance.
The starting point in the risk analysis process is to consider the nature and complexity of the
project at hand. Risk analysis will take time, and any steps taken to avoid or mitigate risk may
negatively impact project schedules and budgets. Therefore, you want to carefully consider the
effort to be put into risk management. A short term, non-production project, such as an internal
review of purchasing procedures, would warrant limited risk analysis. However, the physical
deployment of new purchasing systems, with the potential for operational disruption, could call for
further risk consideration. In view of the operational impact, most technology projects deserve
some degree of risk management.
Once you know that risk management is warranted, begin by identifying the types of probable
risks. Depending upon the nature, complexity and duration of your project, you may encounter
different types of risks. To facilitate identification and assessment, and to pave the way for clarity
in thought and communication, group potential risks into categories. This will allow you to view
risks according to type, source and underlying cause.....
RISK CATEGORIES:
Management Risks: Risks that relate to the scope, structure and strategy of a given project.
Some examples......
The scope and complexity of the project is too large...i.e. are you biting off more than can
be chewed?
Project requirements and outcomes are poorly defined.
The project does not have effective sponsorship or management support.
Technology Risks: Specific technical risks including design omissions, version conflicts,
operational failures, incompatibilities or bugs.
Some examples......
Potential incompatibilities exist within current desktop platforms or internally customized

applications.
Outdated or insufficient hardware exists for running new software products.
Early adopter's risk - early adoption of new technology will limit the ability to benefit from
the experiences of others.
Resource Risks: Human resource risks can involve staff changes, a lack of skilled resources,
staff non-performance, or the reliability and availability of external service providers.
Some examples.....
Continual resource availability may be compromised during lengthy projects.
The loss of key staff to competitors or vendors may occur once they are trained in new
products or technologies.
Timing Risks: Timing and scheduling risks can include product delivery delays, or missed
deadlines along the critical path.
Some examples......
Annual budgets will lapse if product delivery is delayed.
An overly aggressive project schedule may limit the execution of thorough test plans.
Political Risks: Internal sensitivities relating to project support, sponsorship, internal

cooperation and communications.
Some examples......
Is the project dependent upon one individual for visibility and support - and what would
happen if that person leaves the company?
Are project deliverables in alignment with stated company priorities?
Are there any political issues that could negatively impact resource availability and
cooperation?
Are there other competing projects within the company?
Could pending organizational changes impact the project?
External Risks: Risks beyond the direct control of the project team, caused by external
environmental or industry factors.
Some examples......
Potential regulatory changes
Potential economic changes
Potential company mergers
Seasonal issues, including conflicts with holidays or weather related issues
The end result of this risk identification process should be a listing of likely project risks,
organized by appropriate category. This list is your roadmap to the next step.....analyzing and
assessing the impact of these risks, and then ultimately to forming an effective plan for response
and control.
Ideas into Action: The Project Risk Scorecard (Quick Tool)
MORE ABOUT RISK MANAGEMENT POLICIES & PROCEDURES:
The Risk Management Process Kit An all-in-one planning solution to help you produce risk
management "process" deliverables for all your projects. The Kit contains information, advice,
planning forms, and pre-formatted "Plan" templates.
project.
management policies and procedures
HOW TO USE "RISK MANAGEMENT" POLICIES AND PROCEDURES

Effective project risk management relies on information, common sense, experience, and to a
certain degree, intuition. Risks to project completion and ultimate success must be identified and
analyzed.... what can happen, what is the likelihood, and if the worst should occur, what would be
the result? But theory and strategy are only part of the picture. In order to put theory into action,
appropriate procedures must be put into place.... to establish the mechanics by which risk
management theories can be applied.
To put it all into perspective, risk management procedures can be broken down into five structural
elements:
Origination
Assignment
Execution
Oversight
Closure
ORIGINATION:
Risk origination procedures establish the mechanics by which risks are initially identified and
raised for further analysis and consideration. Risk management takes place throughout the entire
life of a project . from start to finish. Therefore, risks can be identified and raised at any time. In
order to ensure that proper attention is paid to each and every risk possibility, procedures should
be established to allow for ready identification at any point in a project.
To that end, risk origination procedures should provide structured formats and methods by which
risks are raised and communicated. Such methods and formats can range from the simple to the
technically complex, and may involve the use of paper forms or electronic databases. But,
whether paper or electronic, the methods and formats by which risks are first raised should
provide for the entry certain basic information.
Preliminary risk data what is the nature of the risk and potential impact on the project?
Risk identifier - to establish a tracking system by which risks can be monitored once
raised, and until closure (i.e. an ID or coding system).
The name of the individual raising the risk.
The date the risk was raised.
A target response date when must this risk be analyzed and addressed?
ASSIGNMENT:
Risk assignment procedures establish the mechanics by which risks are assigned to appropriate
staff members for further analysis and action. Risk assignment procedures should address the
following questions:
Who can originate risks?
Who will be responsible for risk review and analysis?
Who will be responsible for developing and selecting risk response and control
strategies?
Who will be responsible for approving risk assessments and related response and control
strategies?
Who will execute risk response and control plans?
Who will monitor risk status and the progress of any risk management activities?
Who will approve risk closure?
Who will be responsible for reviewing the success of the risk management process?
EXECUTION:
Risk management execution procedures determine the actual steps involved in the risk review
process, establishing the sequence of events and flow of information as risks are identified and
evaluated. For planning purposes, these execution steps can be broken down into seven
elements, as follows:
1. The risk is raised and initially identified.
2. The risk is assigned and prioritized for further action.
3. The risk is reviewed according to established criteria (category, probability, impact &
target values)
4. Risk response strategies are devised (acceptance, avoidance or mitigation).
5. Risk response strategies are approved.
6. Risk response strategies are implemented as needed.
7. Risk management activities as listed above are documented.
OVERSIGHT:
As previously noted, the risk management process is an ongoing effort that lives throughout the
entire project cycle. This is not mean to imply that every element of the risk management process
will be executed in all circumstances. If risks fail to materialize, you may never have to take any
further action for control and mitigation. However, that does not mean that you can avoid risk
oversight. Effective risk management oversight has two unique dimensions status
measurement and progress measurement.
Status measurement: To monitor the status of the risk itself. Whether or not risks ever
materialize, they still have to measured and monitored for any apparent change in status. In the
initial stages of risk assessment at the start of a project, potential risks are identified and
evaluated. At that point in time, it may appear that certain risks are unlikely, or that their impact
will be insignificant. However, as the project ensues, circumstances may change, and risks once
thought to be unlikely and insignificant, can suddenly become very likely, and quite dangerous.
For this reason, potential risks must be continually monitored as a project progresses. You can
never tell when risk conditions will change or when new risks will arise, and to prevent unpleasant
surprises, periodic risk reviews should be undertaken as often as practical and whenever needed.
At the very least, monthly risk review sessions should be built into your overall project
management process.
Progress Measurement:
Risk oversight procedures must also be designed to monitor the timing and completion of all
scheduled risk identification, evaluation and control activities. There are two primary elements to
risk progress measurement, detailed as follows:
1. Management of the risk review schedule, which can include organization and
prioritization of the risk review queue. Progress must be readily measured to ensure that
risks are reviewed on a timely basis, and to maintain a realistic risk review schedule
suited to project circumstances, overall project status, and external resource demands.
2. Management of individual risk activities, to include the status of all tasks and decisions
necessary to manage individual risk events.
Have risk review assignments been completed as needed?
Have response and recovery action plans been completed as needed?
Have risk response plans been properly communicated so that the project team can act
upon them?
Are mitigation activities working?
CLOSURE:
The final element of risk management process is closure . the point at which risks are
sufficiently resolved so that no further action is warranted. This is not meant to imply that closure
only arrives through resolution or elimination. Risk management closure procedures can be
applied at several points in the project cycle.
Risk closure is appropriate when ..
A risk is raised and no further analysis is warranted.
A risk is realized, and response actions are completed so that the risk no longer exists.
The time or circumstances under which a risk can occur expires.
The project is cancelled or completed.
Risk closure procedures involve several basic steps:

1. Risk status is assessed to determine if a risk is "open" (meaning that further analysis or
action may be required) or "closed" (no further action or analysis is required).
2. Risk status is documented. This documentation should address all elements and results
of the risk management process as pertaining to the risks at hand. This should include
the completion of all forms, and documented evidence of the ways and means by which
specific risks were evaluated, as well as the results of the risk response and control
activities.
3. Lessons learned are analyzed and recorded. Every project should conclude with a post
project review, to include a comprehensive Lessons Learned Analysis. Any effective
Lessons Learned Analysis should include an examination of the risk process itself, as
well as an evaluation of risk management processes as a contributing factor to overall
project success or failure.
CONCLUSIONS.....
In their practical application, these five elements will be applied differently within any given
operation or project, depending on project needs and organizational capabilities. The ultimate
goal of risk management is to create realistic processes for resolving project risks, so that time is
well spent, and project results are appropriately protected. Above all, risk management strategies
and practices must be well suited to the projects encountered, and to individual organizational
needs and capabilities.
Ideas into Action: The Project Risk Evaluator (Quick Tool)
The Risk Management Process Kit NEW VERSION!

All-in-one planning solution designed to produce risk management "process" deliverables for all
your projects. The Kit contains information, advice, planning forms, and pre-formatted "Plan"
templates.
project.
management policies and procedures.
ARE YOU READY FOR A RISKY PROJECT?

You have just been asked to take over an important project. Is this cause for celebration or
panic? Before you decide to jump for joy or head for the hills, you need to take a step back to
examine the situation, and answer these questions....
Why is this opportunity available?
Why is the opportunity being offered to you?
Are you ready to take it on?
Do you have a choice?
Why is the opportunity available?

Unexpected project management opportunities can pop up at any time, for any number of
reasons. Perhaps the current project manager is leaving the company, or just moving on to
another project? In this case, the management opportunity is just that an opportunity. But, what
if the project manager is leaving because the project is failing? In this case, an apparent
opportunity may also be a risk. A troubled project could be a boost to your career, or it could bring
an uncertain future.
To evaluate opportunities and risks, you should examine the following questions.
Why is the project management vacancy available? ("normal course of business

opportunity" or "problem" opportunity?)
If you are being asked to step in to save a troubled project, why is the project in trouble?
Is there any reason to believe that the project problems were caused by the departing
project manager, or were the problems related to the project itself?
Has anyone in your organization ever succeeded at this type of project, or will
organizational politics stand in the way of success, no matter how hard you try?
Why is the opportunity being offered to you?

Why me? Self confidence aside, if this assignment comes out of the blue, and is out of line with
your experience and current position, then you have to consider the likely reasons for the
assignment..
There is no one else.
You have a track record as a problem solver.
You have been asking for an opportunity just like this one.
This is a reward for good work.
Internal politics.
Are you ready to take it on?
Before you begin any project assignment, particularly risky ones, you need to evaluate
your own skills and capabilities . are you ready, willing and able to get this job done?
Do you have the necessary skills to succeed on all levels (technical, management, and
political)?
If you do not have the all the necessary skills, what accommodations can be made to
compensate?
Is there sufficient time to acquire or refine the skills needed?
Do you have a choice?

Is this project opportunity an assignment or an option? The distinction may be so small that it
hardly matters. Depending upon how the opportunity is offered, and by whom, you may have the
option of saying no, but at what cost? An outright refusal could put your job at risk, damage your
career, as well as your reputation and relationship with management and peers. Considering the
consequences, it is better to manage the situation to your advantage.
Turning Risk into Opportunity
Even if you cant say no, dont just say "yes". A risky assignment brings consequences. Success
can make your career, and failure can certainly break your career. If you accept an assignment
without voicing any doubts, particularly when those doubts should be fairly obvious, failure could
mean the loss of your job, or at the very least, loss of your reputation. Management memories
can be short, and your manager may suddenly forget that risks ever existed if you fail to voice
your concerns. So, even if you have to accept the assignment, take steps to protect yourself by
clearly stating the risks and negotiating the terms.
Step 1: Identify risks and issues.
Look at the project opportunity carefully and pinpoint problem areas, which may include any or all
of the following:
Lack of funding.
Lack of management support.
Overly aggressive schedules and unrealistic deadlines.
Inappropriate scope.
Lack of skilled resources.
Ineffective technical design.
Insufficient requirements.
Lack of cooperation.
Step 2: Raise your objections.

Make management aware of any and all problems in writing. A clear specification of risks will
serve as a basis for negotiation, and at the very least, will make your concerns a matter of record
for future disputes.
Step 3: Negotiate details.
Identify the tools and resources you will need to mitigate the problems and risks you have
identified, and negotiate practical solutions. For example, if you feel that the project is failing
because the scope is too large, negotiate a smaller scope. If the schedule is too aggressive, try to
negotiate new deadlines. In other words, change the assignment to lower the risk and raise the
likelihood of success.
Step 4: Keep management informed.
Whenever you take on a risky assignment, you need to keep management fully apprised of all
problems and progress. Ask for help whenever you need it, and be sure to continually document
any open issues in writing. Make your management a partner in the risk.
CONCLUSIONS...
So, before you accept or reject any assignment, take the time to analyze the risks. If you have to
say "no", you will need a good reason. If you have to (or want to) say "yes", you will need
sufficient information to turn that "risk of failure" into "an opportunity for success".
Ideas into Action: The Project Risks Scorecard (Quick Tool)
GET READY FOR YOUR NEXT ASSIGNMENT...
more.
and best practices.
HOW TO MANAGE PROJECT CHANGE

Considering the effort that it takes to gather requirements, assemble a team, get approvals, and
put your project down on paper, it's hard to welcome change within any element of your project.
But change is a reality in any project situation. To begin with, projects occur over a span of time,
and with the passage of time, underlying circumstances and conditions can change. In addition,
projects are completed by people, and people have new ideas, recognize mistakes and change
their minds. Under these circumstances, it would be unwise, if not impossible, to proceed with
any project without recognizing, accepting and preparing for the possibility of change.
So, the basic idea is not to prevent change, but to control it. This is the essence of project
change management - to identify, evaluate and adopt changes so that project results are
enhanced. To that end, project should be managed with a structured process designed to
accept positive change and avoid negative change.
And, any effective process for project change control needs to consider the two primary types of
change:
Reactive Change: when changes are necessary to respond to project problems (i.e.
delays, technical failures, funding shortages, resources issues, etc.). In all likelihood,
reactive changes are not optional as long as you wish to sustain or salvage the project.
Requested Change: when changes to project requirements, scope, deliverables or

related management plans are requested by end-users or other project participants.
These changes can arise from new ideas, new information, or new perspectives, and
usually are requested by project customers (i.e. your end-users). In any event, requested
changes are usually discretionary, and therefore, are difficult to control. While certain
changes can enhance and improve a project, if left uncontrolled, excessive change can
lead to problems. Excessive project changes can overwhelm a project to the point where
original benefits are lost, and the project can no longer be completed as expected. The
trick to change control is to continually balance change requests against original project
goals, ensuring enhanced value, without diminishing schedules and results.
THE CHANGE CONTROL PROCESS:
Any effective change control process needs to account for the five basic elements of change
management:
What types of changes will be allowed?
How will changes be requested (procedures and formats)?
How will changes be reviewed?
How will changes be approved or rejected?
How will changes be incorporated into project plans and deliverables?
What types of changes will be allowed?

In order to properly control changes for any given project, you should set change boundaries......
to establish and limit the types of changes you will consider. Obviously, if a change is required to
sustain or save a project, that change must be accepted. But if change is discretionary, then that
change needs to be weighed against established boundaries. For example, within a web
development project, you may be willing and able to change page design to suit end-user
preferences, but you may not be willing or able to add additional functionality (i.e. a shopping
cart). A change on that level would probably change project scope beyond its original purpose.
That is not to say the shopping cart should not be added, but that may be better left to a different
project, on a different day.
In order to set effective change boundaries for a particular project, you will need to consider
several issues:
Value and Priority. If a project is very visible and important, you may need to limit
discretionary changes to very small levels to avoid unwarranted risks.
Timing. If the change request arrives at an early stage in the project, that change can
probably be absorbed, but if the project is more than 50% complete, that same change
may actually interfere with timely completion.
Cost. Project changes can increase (or decrease) project costs. In order to properly
manage changes, you should set limits on change related costs, so that your budget is
appropriately maintained. In addition, for large projects, separate change budgets (also
known as a contingency fund) should be established to set limits for change costs outside
of the original budget. In effect, your initial budget establishes expected costs, and your
change budget controls the costs of subsequent changes.
Impact. In order to maintain proper control of project change, you will need to assess
change impact - i.e. how will a given change impact your project? Will the change impact
scope, deliverables, schedules, resources, or some other project element? With this
detailed understanding, you can set appropriate, yet flexible limits as a guideline for
change review and approval.
How will changes be requested (procedures and formats)?

In order to execute your change control process, you will need to establish workable procedures
and mechanisms for change request initiation. To that end, you should to address the following:
How will changes be requested - on paper, email, or some other change request system?
Who has the authority to request a change?
How will requests be received and logged for further action?
At a minimum, change request forms or databases should include the following information:
Name of the Project (including any coding system you use to track projects)
Name of the Requestor
Date of the Request
Change Request Number or Code (to track change requests)
Description of the Change (detailing the change and explaining the benefits)
Disposition Status (Approve or Reject)
Signature Lines
How will changes be reviewed?

Once change requests are submitted and documented, these requests have to be reviewed to
assess value, timing, cost and impact. In order to deal with change requests in an efficient, timely
manner, you should establish a structured process for change request review, addressing the
following:
What is the required turn-around time for review?
Who is responsible for change request review? (i.e. individual team members, the project
manager or a change review team?)
How will changes be approved or rejected?

Depending upon project specifics, and the size and structure of your project team, request review
activities can be undertaken as a separate step, or can be combined with the related activities for
approval/rejection. A separation of review and disposition tasks can serve as a project "check and
balance", whereby one individual (or group) has responsibility for assessing and recommending
change action, and another individual (or group) has responsibility for actual approval or
rejection. Whether one process is used, or separate steps are followed, change disposition
should address the following:
What is the required turn-around time for change request approval or rejection?
Who is responsible for approval and rejection?
How will the approval or rejection be communicated and documented?
Will there be an official process for appeal?
What procedures and formats will be followed to ensure that change request rejections
are fully documented (explaining the reason for the rejection)?
How will changes be incorporated into project plans and deliverables?
Once change requests are processed, reviewed and approved, the corresponding changes have
to be incorporated into the ongoing project. Depending on the specific type of change, one or
more elements of the project may be affected, and this may necessitate changes to project plans,
technical designs, resource assignments, budgets or other project documentation. No matter
how many areas of the project are affected, changes should be recorded to ensure that original
documents and plans are maintained as a baseline, with changes clearly identified. Most
automated project planning tools will track changes to plan, and will produce reports of all
variations. However, as time passes, and with multiple projects underway, these reports may not
provide sufficient "lessons learned" information as to the "whys and wherefores" of change
approval, and the related change results. To that end, a Change Impact Statement can be used
to record change reasoning, execution and consequences. The Change Impact Statement
should document approved changes from several perspectives:
What was the nature of the change?
Why was it approved?
How was it executed?
Were the anticipated consequences realized?
Was the change positive or negative, and what can be learned for the future?
CONCLUSIONS....
Change control procedures should be used to assess, track and manage inevitable changes, but
procedures and standards are only part of the picture. To effectively manage project change, you
will also need to sharpen communication and negotiation skills. In the event that a change
request is denied, you must be able to communicate and justify that decision. In the event that
resistance is encountered, you will probably need to negotiate some sort of compromise. And, on
the flip side, should an approved change result in unexpected negative consequences, you will be
expected to justify your approval decision. Change management is a risky, sensitive process,
requiring a combination of planning skills, communication, logic, experience and common sense.
Any steps taken to structure the process will help you meet those challenges.
WORKBOOK PRODUCTS
more.
and best practices.
review of deliverables, procedures and participation. This Kit provides a fast path
HOW TO TRACK AND MANAGE PROJECT ISSUES

Issues happen. As any project proceeds, questions and problems arise, and if the course or
outcome of the project hangs in the balance, then an "issue" is born.
Looking at this definition, it appears as if project issues and risks are one and the same.
Although the distinctions may be subtle in nature, issues differ from risks in terms of predictability
and management approach. The fact that issues will arise is predictable, but the specific
substance of any given issue is not. Risks are predictable circumstances, those which should be
identified before a project begins. As such, long term strategies can be developed to avoid said
risks, allowing for the application of defined management solutions should the risk be realized.
On the other hand, issues can pop up at any time during a project, and must be dealt with quickly,
without the benefit of pre-defined solutions. Typically, project issues involve the project
deliverable itself, in the form of unexpected technical problems, incompatibilities, bugs or other
conflicts. However, during the course of a project, it is likely that other issues will also arise,
relating to project schedules, resources, materials, finances, or other unexpected changes in the
project environment.
Just because you can't predict issues, doesn't mean you shouldn't be prepared to handle issues
once they arrive. Every project should begin with a defined process for issues management.
An effective issues management process should cover the following bases:
Goals: what are you trying to accomplish with the process? In all likelihood, your issues
process should be designed to ensure that all issues are identified and resolved in a
timely fashion, keeping all parties informed as needed to get the job done.
Capabilities: what tools will be used to raise, resolve, and track issues as they arise and
as they are closed?
Origination: how will issues be raised to the project manager?
Evaluation: how will issues be reviewed and assigned?
Tracking: how will issues be monitored and tracked for timely resolution?
Escalation: how will issues be escalated in the event they cannot be resolved and
closed?
All of these requirements should be reflected in your issues management mechanism,

consisting of the tools and procedures by which issues are raised, resolved and managed. Your
issues management mechanism will have two elements.... a physical element (software, online
form, paper form) and a logical element (management strategies and procedures).
Physical Issue Management Mechanisms:

Whether you track project issues on a piece of paper, or in a database system, you will need to
collect and track the following types of information:
Issue Type: to categorize issues for easier assignment and tracking. Issue categories
may vary be project type, but can usually include the following:Technical: an issue
relating to the technical aspects of the project process or deliverable itself.
Financial: an issue relating to project funding, spending or budget.
Resource: an issue relating to project resources (equipment or people).
Schedule: an issue involving the project timeline.
Other: a unique issue specific to the project at hand.
Issue Description: to identify the specific nature and impact of the issue (what is the
issue all about and how does it impact the project in terms of deliverables, schedule,
costs, scope or other parameter?).
Issue Originator: who first raised the issue?
Issue Date: the date the issue was raised.
Issue Owner: who is responsible for issue resolution?
Issue Identifier: a unique code or number to track issue status.
Issue Status: to track issue status:

Open: Issue resolution has not yet begun.
In Progress: Issue resolution is underway.
Closed: The issue has been resolved.
Escalated: The issue has been escalated for further management action.
Issue Priority: to ensure that issues are dealt with appropriately considering impact and
consequences:
High Priority: Issues having a major impact on the project, requiring immediate attention.
Medium: Issues have a moderate impact on the project, requiring attention in the near
future.
Low: Issues having an insignificant impact on the project, requiring attention at some
future date if time permits, or not at all.
Target Completion Date: to establish a timeframe for resolution.
Resolution Description: to identify the steps taken to address and resolve the issue.
Logical Issue Management Mechanisms:

Once an issue is raised and documented, resource assignments must be made. Depending on
the nature of the issue, any project team member or resource may be involved. For example, an
unexpected bug in a piece of software will likely be assigned to a technical team member, who
may be called upon to resolve the problem, or who may have to track the problem with a vendor.
On the other hand, an issue of an administrative nature (i.e. the lack of available facilities for
staging new equipment) may be assigned to a facilities manager, who may otherwise have limited
involvement in other aspects of the project.
A key challenge in issues management is knowing how to make effective issues
assignments. Since most issues must be resolved quickly, with little fanfare, it is
important to assign issues to those who can hit the ground running whenever possible.
Another key challenge in the issues process is to track issue status, from the point at which
issues are first raised and assigned, through to resolution. Depending upon the complexity and
visibility of any given project, you may need to hold ongoing issues meetings.. Issues meetings
can bring an important perspective to the project process, providing the opportunity for the entire
team to consider issues, plan actions and take a "big picture" perspective. These meetings can
take place as needed, on a daily, weekly or monthly basis, to ensure that issues are properly
tracked and managed.
CONCLUSIONS.....
As you work to resolve issues, you need to look at solutions that can solve the problem, with the
least impact on the project schedule, budget and scope. When handled quickly, issues offer the
opportunity to refine and improve project results. In addition, any organized issues management
record will likely provide valuable insights and experiences for your next project.
Ideas into Action:
The Project Issues Form (Quick Tool)
WORKBOOK PRODUCTS:
more.
and best practices.
HOW TO MANAGE PROJECTS USING PROGRESS CHECKPOINTS

Projects occur as a series of phases, structured along a timeline designed to produce
deliverables, meet stated goals, and utilize allocated resources. Without this structure, projects
would prove unmanageable as the work effort would just be too massive and undefined.
As a project begins, the initial blank slate can be overwhelming. Phases put the work to
be done into perspective, replacing the blank slate with a framework for planning. Phase
management also provides the opportunity for periodic review and reflection to examine
progress at key points, ensuring that the project is proceeding as planned and required.
To take full advantage of these potential benefits, each phase must include checkpoints for
management control, also known as stage gates or exits. Checkpoints provide a basis for
analysis and evaluation, to determine whether the project is proceeding as planned, and to take
corrective action as needed.
Every project phase should pass through the checkpoint gauntlet to ensure that essential goals
and deliverables are being met, and to identify potential issues and problems in stages, before
they become overwhelming.
Checkpoint Planning and Identification:
For full benefit and impact, checkpoints should be identified according to specific project phases,
and as needed to ensure the timely advancement of project goals and deliverables. Checkpoints
must be structured to answer one primary question are you ready for the next phase? If the
answer is yes, the project proceeds. If the answer is no, other action must be taken, to include
progress with corrective/compensating actions, project suspension, or outright cancellation.
To illustrate checkpoint utilization, we can examine a typical five - phase IT project. For
analytical purposes, this project is structured as follows:
Phase 1: Requirements
Work Effort: To define technical and business requirements for the project.
Phase 2: Design
Work Effort: To design the technical deliverables.
Phase 3: Development
Work Effort: To develop and test the technical solution.
Phase 4: Implementation
Work Effort: To deploy and support the roll-out of the technical deliverables.
Phase 5: Closure
Work Effort: To transition the project and deliverables from project status to operational status.
The Checkpoint Illustration: The following chart illustrates the types of questions to be
considered as a project moves from one phase to the next.....
From Phase..... Checkpoints......
Phase 1:
Requirements
Phase 2:
Design
Have all "requirements" tasks been completed?
Are there any open issues?
How will these issues be resolved?
Are the established requirements sufficient to

proceed to the next phase?
Have all "design" tasks been completed?
Does the design meet the established
To Phase....
Phase 2:
Design
Phase 3:
Development
requirements?
Phase 3:
Development
Phase 4:
Implementation
Phase 5:
Closure
Are there any open design issues?
Does the design function as expected?
Is the design ready to proceed to the next phase?
Have all "development and testing" tasks been

completed?
Does the system perform as expected?
Are there any open development issues?
Is the system ready to proceed to the next phase?
Have all "implementation" tasks been completed?
Is the project ready to proceed to the next phase?
Have all "closure and transition" tasks been

completed?
Have all necessary "closure and acceptance"

approvals been obtained.
Has the lessons learned review been completed?
Can the project be closed?
Phase 4:
Implementation
Phase 5:
Closure
Project
Complete
The Checkpoint Planning Process:

Step 1: Break the project down into logical phases.
Step 2: Define each phase in terms of goals, start and end dates, key tasks and milestones,
deliverables and resource requirements (people, time and money).
Step 3: Specify phase checkpoints.
Step 4: Specify checkpoint alternatives:
Go = Checkpoint passed. The project can proceed to the next phase.
No/Go = Checkpoint failed. The project should not proceed to the next phase without
some type of compensating or corrective action, suspension or cancellation.
Step 5: Identify checkpoint participants and decision-makers:
Who will make checkpoint recommendations?
Who must approve checkpoint recommendations?
How will checkpoint decisions be communicated and implemented?
Conclusions:
Checkpoints can present difficult choices. Every checkpoint analysis requires an objective
examination of the project to date. This can be a difficult task for the project manager and the
team who have so much invested in every project. At times, checkpoints will not be passed, and
unpopular actions must be taken, up to and including project cancellation. But, when project
viability is in doubt, it is better to walk away than to proceed with a non-viable initiative.
Checkpoints can provide a much needed safety net to prevent wasted time and resources.
Related Quick Tool:
The Checkpoint Planning Worksheet
WORKBOOK PRODUCTS: IT Management Workbooks are produced and published by Right
Track Associates, Inc., creators of ITtoolkit.com.
The Project Planning Checklist ($5.95)
Use this project planning template to plan and track "process" tasks, issues and deliverables and
checkpoints.
The Project Planning Roadmap ($14.95)
The Project Communications Process Kit ($39.95)
more.
The Project Standards Policy Kit ($24.95)
and best practices.
The Project Review Survey Kit ($94.95)
HOW TO PLAN TECHNOLOGY MIGRATION PROJECTS

While specifics may vary by the technology involved, technical migration projects all have certain
common elements, and can therefore be tackled with certain common approaches. Every
migration project has a starting point.... an existing system, and an end game .... a new system,
and the project is defined by the road that must be traveled to get from Point A to Point B....
The variations on the migration project theme lie in the details ...
The nature of the technology itself ... migration projects can and do involve many
technical levels in terms of hardware, software and infrastructure....
The technical complexity of the migration solution....
Internal skills and capabilities for handling the migration....
The reason for the migration....
The value to the organization....
The sense of urgency....
Any resistance to change from end-users and IT staff....
As this list illustrates, any pending technical migration can be quite overwhelming at first ..... not
only do you have to get something installed and working, you have to get it right the first time,
with minimal disruption to business operations. And, considering that migration projects are all
about replacement ... moving from one system to another, you may have a small window of
opportunity for the conversion, not to mention the possible psychological resistance to change on
the part of end-users and IT staff.
Considering the complexity of these issues, it is wise to alleviate as much pressure as possible
from the very start. There is no need to approach every migration project as a new experience
when common elements exist in every migration enterprise. It makes sense to take advantage of
that experience and to facilitate planning and execution with the use of a structured migration
project planning methodology. This methodology can be used to create a consistent
framework for migration planning, using common elements as a launching pad, so that you can
focus in on the details.
The Migration Project Planning Methodology
An effective migration planning methodology should address two primary issues....
The structure of migration projects.
Roles and responsibilities within migration projects.
PART ONE: MIGRATION PROJECT STRUCTURES

Migration projects can be structured logically into seven basic phases:
Phase 1: Needs Analysis
Phase 2: Technical Design and Development
Phase 3: Testing
Phase 4: Migration Planning
Phase 5: Migration Implementation
Phase 6: Post Migration Support
Phase 7: Closure
Phase One: The Needs Analysis

This phase deals with the identification and analysis of key requirements, which form the basis for
future planning.....
what are the technical requirements for this migration?
what are the reasons and business benefits of this migration?
are there sufficient skills and internal resources to carry it off?
what will it cost?
what end-user concerns and needs must be addressed?
what are the timing requirements?
how will the migration solution be developed and tested?
Phase Two: Technical Design & Development

This phase involves the actual development and design of the migration solution. Two primary
issues must be addressed in this phase....
the design of the end-game (the new system)
the technical migration method - (how will we get from the starting point to the endgame?)
Phase Three: Testing

This phase involves the testing of the technical design created in Phase Two. Depending on
individual circumstances, this testing can take place in a lab setting, or via a pilot program.
Whatever test method is chosen, this phase should address the the following issues....
test plans for the migration solution itself (i.e. does the new system work?)
test plans for the migration method (does the conversion plan work?)
a roll-back process should the migration fail.
Phase Four: Migration Planning

This phase involves the creation and documentation of the actual migration plan, based on the
results of the aforementioned three phases. This phase should accomplish the following ....
To translate technical decisions and activities into a manageable migration project plan in
consideration of technical requirements, resource availability, timing, training, and enduser needs.
To apply standard project management practices to the migration plan, including risk
assessment, status reporting, communications planning, change control and other related
procedures.
Phase Five: Migration Implementation

This phase involves the actual implementation of the migration plan, including technical
installation and conversion, as well as the related training of end-users as needed to complete the
migration.
Phase Six: Post Migration Support
This phase involves all activities relating to support of the migration result (i.e. new system) as
may be required. This support can include....
On site problem management
Help Desk Support
Additional end-user training
Change control management
Phase Seven: Closure

This phase will close the Migration Project, transitioning the new system to ongoing operations
and support. Beginning as soon as all migration specific issues have been resolved in Phase Six,
this phase should include....
Finalization of all project documentation.
Completion of all technical documentation for the new system.
Disposal or reallocation of any hardware or software remaining from the replaced system.
Completion of a post migration review and Lessons Learned Analysis.
When executing these seven phases, each can be completed as independent sub-projects,
connected via a series of checkpoints. These checkpoints exist to enable the "go / no-go"
decision. For example, after the Testing Phase, you may find that you are not ready to proceed
to Migration Planning. At that point, you may decide to abandon or postpone the migration
project, or you may need to go back to the technical drawing board - to do more work on
requirements or more work on technical design.
PART TWO: MIGRATION ROLES & RESPONSIBILITIES:
In order to execute the migration project structure outlined above, you will need to have the right
set of resources, fully informed of their respective roles and responsibilities, which can include....
The project manager - to plan and oversee the migration project.
Technical development and design staff - to create the migration solution and the
method for conversion.
Technical testing staff - to develop and execute test plans to validate the migration
solution and the conversion methods.
End-user liaisons - to work with the end-users to establish migration requirements, and
to communicate concerns and issues back to IT.
Training staff - to instruct end-users in the use of new systems as needed.
Technical implementation staff - to carry out the migration plan from a technical
perspective.
Technical support staff - to provide migration support, during and after the migration
process.
Technical writers - to prepare technical documentation.
Realizing that IT shops come in many shapes and sizes, it is quite possible that one individual
may wear many of these hats within the execution of a migration project. Even though you may
not be part of a large IT group, the use of a structured approach to migration planning can still
facilitate the overall process, ensuring that all issues and concerns are sufficiently addressed. In
this way, you can make your life easier, and increase the likelihood of success.
Ideas into Action:
The WBS Building Blocks Worksheet (Quick Tool for project planning).
more.
and best practices.
HOW TO DEFINE PROJECT SUCCESS: "IN THE EYE OF THE BEHOLDER"

Was your last project a success? The answer may very well depend upon who is asked, and
their particular definition of success. As a project manager, (or someone who finds themselves
managing projects), you may expect that if you complete a project on time, within budget, and
your end-result works, that you will have achieved success. This seems logical, but it not always
true.
Consider this example.....
A project is completed on time, the end-result works, and the budget was met, but the project
team had to work extra hours and every weekend for two months because the project schedule
was overly aggressive and the project plan did not properly account for problems. Was this
project a success....?
The answer is likely something along the lines of "it depends", "yes, but...." or "not in every
respect". In any event, it would be difficult to view this project as a success on all counts. As this
example shows, project success cannot be viewed from a single perspective. Your end-users
may not even know or care that your project was not planned well as long as the end-result
works. But to your burnt-out project team, that same project could hardly be called a success.
And, this is not only an important issue of the moment. If the project team is burnt-out, the next
project manager who must rely on that same team for future successes may have real cause for
concern. As this one example illustrates, your ability to consider a project a "success" will go well
beyond immediate budgets and deliverables.
Considering that success can be so subjective, it is wise to not limit yourself to a single
definition. Instead, the creative, but realistic project manager should promote a different
concept.... that projects can be successful on many levels, and that a failure on any
particular level is not necessarily determinative of overall success, or failure.
WORKING TOWARDS PROJECT SUCCESS.....
The true definition of project success arises from multiple perspectives, and will vary from project
to project. Any examination of success should not begin at the end of a project, but at the very
start. Success begins with consensus amongst all project participants and stakeholders ..... what
will it take to make this project a success?
The answer to this question will form your success criteria - the agreement between all parties
as to the meaning of "success" for a given project. Success criteria should be defined from the
start as a basis for project initiation - along with goals, deliverables, scope and requirements. It is
an important project element .... you need to know what you are working towards, and you also
need to know that everyone is on the same page "success-wise".
Any useful definition of success criteria should account for variations in perspectives and
dimensions. To that end, success criteria can be viewed from three distinct points of view ....
Deliverables Success - relating to the end-result of the project (products or services),

including issues of quality and fulfillment of requirements.
Procedural Success - relating to the way the project was organized, structured and
managed, including timeliness, cost control, effectiveness of the project plan, and
adherence to established project management standards.
Staff Success - relating to the "human resource" elements of the project, including
resource utilization, staff perspectives, interactions and team relationships.
These three categories set the stage for the definition of workable success criteria, but underlying
specifics will probably vary according to the project at hand. For that reason, success criteria
should be created for each and every project encountered, and should be tailored to suit
individual project circumstances. Above all, success criteria should be simple and attainable.
And, once defined, they should also be ranked according to priority.
The issue of priority may seem a bit illogical, after all, your overall goal should be for success on
all levels, right......? We can all agree on that goal, but unfortunately, even the best of intentions
run up against unexpected problems now and then. If hard choices have to made in the midst of
a project, success criteria priorities can provide a basis for sacrifice ..... For example, if your
project participants have established the quality of deliverables as a priority over timeliness, you
will have some clue as to how to react should project delays occur.
The following list provides an illustration of the use of multi-dimensional project success
criteria......
o
Project deliverables are to be delivered according to requirements and

specifications. (Deliverables Success)
The project is to completed with no more than 10% schedule overruns. (Procedural
Success)
Project expenditures are not to exceed the estimated budget by more than 10%.
(Procedural Success)
The project management process is to be followed without exception unless

authorized by the Project Director. (Procedural Success)
Project change requests shall not be allowed to interfere with project schedule or
budget. (Procedural Success)
Project staff resources are to be utilized effectively, and will acquire new skills as a
result of the project. (Staff Success)
Project overtime shall not exceed estimations by more than 5%. (Staff Success)
EVALUATING SUCCESS.....
At the end of a project, success criteria can be used as basis for evaluating project performance.
And, if you looked at success from a single perspective, you would miss important indicators for
future performance improvements. As we have previously discussed, projects can fail or succeed
on any number of elements, and can still be considered a success if overall priorities and
objectives are met. But that does not mean that there is no further room for improvement. As
you go through your post-project review, you can use your success criteria as a benchmark for
evaluating overall project performance....
Were success criteria met?
If the answer is yes, how was that accomplished, and how can we ensure that our
successes are repeated?
If the answer is no, why did we fail to meet our success criteria?
Which criteria did we fail to meet?
Why did each failure occur?
Were the success criteria realistic and attainable?
What improvements can be made in the future to the way we plan deliverables, execute
projects or utilize project staff resources?
CONCLUSIONS......
Success is the obvious goal of every project .... but it should not be an unspoken goal, nor should
it be taken for granted. If you take the time to consider success from multiple perspectives, you
will make future project successes more likely and easier to attain.
WAS YOUR LAST PROJECT A SUCCESS?
The Project Review Survey Kit Valuable lessons are hidden in every project - will you be ready
to take advantage? There is no better mechanism for performance improvement than past
experience. The Project Review Survey Kit will show you how to evaluate project performance
and uncover valuable lessons learned. Learn how to plan and conduct a review process for any
type of project, taking positive steps to identify lessons learned, correct performance problems,
and strengthen future successes.
WILL YOUR NEXT PROJECT BE A SUCCESS?
The Statement of Work Process Kit: In an easy, immediate download, you get how-to advice,
(5) smart forms for planning, review and approval, and (2) templates (one in PDF format and one
in Microsoft Word format) for actual Statement of Work document preparation.
Top Ten Project Success
Project success is too often defined

as "on time and on budget". In a
larger sense, true project success is
an intangible, realized through
consensus, collaboration and
communication. Click on the links to
learn more...
Use standards and best practices to minimize project planning redundancies.
Make sure your projects are based on sound, solid requirements.
Define project management success before you begin.
Once a project is underway, keep changes to a minimum.
Organize your project team according to needs and organizational realities.
Don't be caught by surprise - use checkpoints for management control.
Keep your project customer engaged in the project from start to finish.
Test, test and test again.
Transfer responsibility to the customer once the project is complete.
10
Evaluate every project for valuable lessons learned via post-project reviews.
GRACEFUL EXITS TO TROUBLED PROJECTS

How to plan project cancellations.....
Projects can fail for any number of reasons ... poor definition, poor planning, lack of commitment
.... and the list goes on. No matter the reason, when you find yourself in the midst of a troubled
project, you need a way out --- quickly, cleanly and with minimal damage. But, before you rush
to cancel any project, you need to be certain that cancellation is the best and most viable
option.
Assumption: To warrant a troubled project assessment, you should have clear and credible signs
that a project is in trouble .... i.e. you are behind schedule, deliverables are not working out as
planned, the project team is not working well together, etc...
1. Why is the project failing?
As we have already noted, projects may be headed towards failure for any number or
combination of reasons. If you are to react properly, you must be able to readily identify those
reasons as they apply to a project at hand.....
o
Project is a Bad Idea
Poor Planning
Lack of Resources
Lack of Funding
Overly Aggressive Schedules
Technical Problems
Vendor Failures
Business Priorities Have Changed
Lack of Skills
Poorly Defined Scope, Deliverables or Objectives
Insufficient Management Oversight
Lack of Team Commitment
Lack of Management Support
Other .....
2. Is there any other viable alternative to cancellation --- can this project be saved by .....?
o
Re-working project plans?
Reducing project scope?
Revised deliverables?
Staff changes?
Changing management?
Revised schedules?
Adding more funds?
Reorganizing the project team?
Strengthening management oversight?
Some other method.....?
3. Is cancellation possible?
It may be difficult, if not impossible, to cancel certain projects, no matter how troubled they may
be. These projects may just be too critical or too visible. In this instance, you will need to look
towards repair as a solution ....taking all possible steps to salvage the project in lieu of
cancellation.
4. What are the benefits of cancellation?
When you cancel a project, you need to be sure that cancellation is the best course of action.
Project cancellation can yield many benefits, even though it signals the end of a previously
chosen project initiative. When a project is cancelled it can save money, time, and free up
resources to work on more important, potentially successful projects.
5. Do you have cancellation consensus?
Project managers rarely have the ability to cancel a project unilaterally, and even if they did, it
would be unwise to exercise that power without consultation and consensus. A cancelled project
is not necessarily a management failure, particularly when the cancellation is appropriate and
timely. But it is important to have the buy-in of all key project participants - sponsors,
management, end-users and team members.
6. What is the cancellation impact? what will cancellation mean to.....?
o
Project Staff
End-Users
Contractual Obligations
Regulatory Requirements
IT Credibility
Internal Politics
Other Projects Underway
Other Considerations....?
7. Will cancellation be temporary or permanent?
It may be possible to revive a troubled project at a later date, when timing and circumstance may
yield better results.
PLANNING THE CANCELLATION:
Should your assessment show that cancellation is the best, most appropriate course of action,
that cancellation should be conducted in a structured, orderly fashion.....
Prepare a Project Cancellation Statement, explaining why, how and when the project is
to be cancelled.
Consult with supporting departments as needed ....(i.e. Legal and Human Resources) to
ensure that your cancellation approach is appropriate.
Obtain all necessary management approvals.
Inform the project team and all major stakeholders.
Formally announce the project cancellation as needed according to the nature and
visibility of the project at hand.
Re-assign project team members to other projects or to return to regular work

assignments.
Release contractors and temporary staff as needed.
Complete a post project review.
Finalize project documentation and retain as needed for future projects, or for any
potential project revitalization.
CONCLUSIONS......
It is important to remember that project cancellation and failure are not the same thing .... why
you may sometimes need to cancel trouble projects, that very act of recognition can be a sign of
management strength and success....
Ideas into Action: The Project Issues Form (Quick Form)
Related Workbook Products from ITtoolkit.com
The Troubled Project Assessment
Use this project control template (in Word format) to help you assess troubled projects and plan
appropriate responses. Using the template, you will assess troubled projects according to (10)
established criteria, evaluate alternatives to cancellation, identify cancellation consequences, plan
"next steps" and document specific conclusions.

Stop project problems before they begin. To avoid costly mistakes and frustrating recriminations,
projects must be clearly defined from the outset, and steps must be taken to ensure that all
stakeholders and participants share the same vision. The Statement of Work Process Kit gives
you a complete system of steps and tools to define and document your "project vision", wrapped
up in an easy five-phase workflow.
PROJECT-SPEAK: QUALITY MANAGEMENT

What is quality? According to the American Society for Quality, quality is defined as:
"A subjective term for which each person has his or her own definition. In technical usage,
quality can have two meanings: 1. the characteristics of a product or service that bear on
its ability to satisfy stated or implied needs. 2. a product or service free of deficiencies.
This definition ably illustrates the elusive nature of quality in the project environment....
Quality is subjective i.e. in the eye of the beholder (in this case, the project sponsor
and customers).
Quality is multi-dimensional determined by the degree to which the deliverable

(product, process or service) meets customer needs and expectations, and, the degree to
which the deliverable is free of defects.
Quality varies according to specific project needs and circumstances.
What is quality management?

Quality management is the process by which quality is defined, produced and controlled within
the project environment. Quality management is not a entirely independent project process. In
fact, quality management has close tie-ins to many other project processes, to the point where
quality management is often indistinguishable from its partner - processes .....
Requirements Planning: Project "requirements" form the basis of quality expectations

and specifications. (more about requirements)
Risk Management: The risk management process is used to evaluate the likelihood and
impact of quality failures. (more about risk management)
Change Management: Change control practices are used to maintain quality

expectations by limiting unwarranted changes to deliverables and scope. (more about
change management)
Issues Management: The issues management process is used to identify potential

quality defects as soon as they arise to enable resolution early on in the project lifecycle.
(more about issues management)
Status Reporting: Ongoing, scheduled status reporting is used to ensure that the
project manager is advised of potential quality defects and problems as soon as they
arise.
Project Performance Evaluation: The project review process is used to evaluate

"quality management" effectiveness, and to improve future practices. (more about
lessons learned)
Quality Management in Practice:

Within the project environment, quality management must be applied to two distinct targets.
Process Quality: Relating to the processes used to plan, manage and execute projects.
Deliverables Quality: Relating to the quality of specific project deliverables (products, services
and strategies).
Quality management is an ongoing process, applied within projects at a global level (through best
practices and standards) and at the per-project level, where quality specifications and
management steps are applied according to specific project needs. Process quality and
deliverables quality are joined at the hip ... while high quality processes cannot guarantee high
quality results, low quality processes will certainly impede high quality results. As such, the quest
for quality, whether for process or deliverables, must address the following key elements:
1) Management Objectives - what are you trying to accomplish through quality management?
2) Quality Specifications - how is quality to be defined for your projects?
3). Quality Consensus - how will these quality definitions be applied, approved and accepted?
4) Quality Control - how will quality be managed and measured as the project proceeds?
5) Quality Defect Correction - how will quality defects be analyzed, mitigated and removed?
Quality management must be driven by tangible goals and objectives....
To achieve project success on all essential levels (results, costs, time and customer satisfaction),
quality management must be more than just an administrative exercise. As a process, quality
management must be deployed to achieve certain essential goals.....
To minimize the subjective nature of quality by defining quality in clear, measurable

terms.
To produce results that meet quality standards, within project scheduling and budgetary
requirements.
To minimize costly defects and errors.
To eliminate costly and non-productive re-work (having to do the same work over again
to eliminate defects).
To maximize customer satisfaction.
To maximize team morale, performance and productivity.
Quality must be defined through tangible, measurable specifications.....

Meaningful, actionable quality specifications result from collaboration and consensus. Since
quality is in the eye of the beholder (the project sponsor and customer), the project team cannot
be the primary arbiter of quality. The project sponsor/customers must define their own set of
quality expectations, and the project manager and his/team must then mold these expectations
into actionable specifications and tangible results. If customer quality expectations cannot be met
for tangible reasons (technical, timing or cost), the project team must work with the customer to
build realistic expectations and consensus.
Specific quality specifications will vary according to intended target (process or deliverable).
A) What constitutes process quality?
Relevancy: The degree to which the process is pertinent and applicable to project needs
and organizational capabilities.
Flexibility: The degree to which the process is sufficiently flexible to suit varying project
needs and circumstances.
Productivity: The degree to which the process makes the most of available time and
resources.
Efficiency: The degree to which the process produces maximum results in the least
amount of time.
Usability: The degree to which the process is easy to use and follow.
Completeness: The degree to which the process contains all required elements for a
complete, fully applicable workflow.
B) What constitutes deliverables quality?

Quality specifications will vary based on the specific deliverable at hand (software, hardware,
service, plan, proposal, strategy, etc). see Project-Speak: Deliverables
Completeness & Correctness
Alignment to Business Needs
Alignment to Technical Requirements
Alignment to Customer Expectations
Form and Function
Performance
Availability
Reliability
Serviceability
Usefulness
Accuracy
As deliverables quality is defined, certain basic questions and conclusions must be addressed:
What is your quality goal? Do you aim for zero defect, or do you aim for a best quality
compromise? The answer will lie in a balancing of the relevant costs and benefits, coupled with
a realistic assessment of capabilities. see Calculating Quality Management Overhead
Quality specifications must be communicated, confirmed and accepted through informed
consensus....
One of the most important goals of quality management is to minimize the subjective nature of
quality through tangible definitions and standards. But definitions alone are not enough. An
effective quality management process must provide the means and mechanics by which said
definitions are documented, communicated, reviewed, revised and accepted. Throughout the
span of any project, the following plans and documents can be used to ensure that quality
specifications are clearly stated and approved:
Quality Management Plans
Quality Specifications
Acceptance Criteria (see the Acceptance Criteria Worksheet)
Success Criteria
Risk Management Plans
Change Request Documents (see the Change Request Form)
Quality must be managed and controlled throughout the course of the entire project....
In order to achieve expected results, quality requirements and expectations must be clearly
stated and defined. But definitions are only a beginning. Once a project is underway, quality must
be continually managed and assessed to ensure that these requirements and expectations are
fully realized.
Quality control takes place at various points in the project cycle, through a number of validation
and verification activities and techniques:
Manual Reviews/Testing (see the Test Plan Checklist)
Automated Reviews/Testing
Prototypes
Pilot Programs
Lessons Learned Reviews (by peers and customers)
Quality Audits (by a third party)
Quality defects must be repaired and removed.....

Defects happen. Considering the fast paced, cost constrained nature of most technology projects,
zero-defect is an admirable goal, but it may not be a realistic goal. The goal of quality
management is to set realistic quality objectives, define quality expectations, ensure minimal
defects and eliminate re-work. But, when defects happen, they must be corrected. As such, the
quality management process must account for all activities and strategies needed to achieve
quality correction, to remove and recover from quality defects, errors and omissions.
CONCLUSIONS
Quality management activities will vary based on the size and scope of the project at hand. At a
minimum, the quality management process must be designed to:
Identify and set relevant quality specifications as part of the project initiation process.
Communicate quality specifications through documented acceptance criteria.
Ensure that all stakeholders understand and accept these quality specifications.
Ensure that the project is executed with the use of established project management
processes.
Build the deliverables based on quality specifications.
Review and test deliverables on a periodic basis to ensure adherence to quality

specifications. Note: This is where project variations will likely have the greatest impact.
Deliverables type, complexity, value and risk will determine review and test scope, test
methodologies, and frequency.
Measure "quality success" with the use of the lessons learned analysis (interim or postproject). This lessons learned analysis should be designed to address both process and
deliverables quality.
Quality management cannot guarantee project success (i.e. a bad idea may be executed
perfectly, but it is still a bad idea.), but if quality is not a driving force in project planning and
execution, success will be a far more elusive goal. As with any other process, quality
management is a matter of balance. Quality management procedures cannot be too
cumbersome, where cost overhead is excessive, or where project deliverables are unnecessarily
delayed. In addition, zero defect does not define quality. Quality is achieved when business value
is met, customers are satisfied, and all tangible quality defects are resolved as needed.
Related Reading: Calculating Quality Management Overhead
SMOOTH TRANSITIONS: HOW TO PLAN PROJECT CLOSURE
All projects must come to an end, one way or another. While some projects may come to an
untimely end through cancellation, most projects reach their planned conclusion. Projects are
designed to produce a specific unique outcome, and when that outcome is delivered, the project
should end. This "end" can be a process in and of itself, normally referred to as project closure.
Depending on the nature and complexity of the project, closure can consist of any or all of
the following elements:
1. Final testing of project deliverables as needed.
2. Formal acceptance of project deliverables based on pre-defined acceptance criteria.
3. Formal production turnover. (the transfer of project deliverables to operational status).
4. Review and analysis of non-critical "open issues".
5. End-user training (covering deliverables usage and maintenance as needed).
6. Operational and administrative training (for production/operations staff).
7. Deliverables documentation (end-user and operational).
8. Resource re-allocation or release (to transfer project staff to other projects, back to
operations, or to release outsourced resources).
9. Post project performance reviews (lessons learned analysis).
10. Project team and staff performance reviews.
11. Vendor performance reviews.
12. Release of final payments to vendors or contractors.
13. Formal closure event planning, to include staff recognition and to mark outstanding
project achievement.
Planning for Closure:
To a large extent, project closure planning takes place before the project begins. To properly plan
any project, you have to envision the end-game . how and when will your project end?
As such, the following closure issues should be addressed as you initially define and structure
your project.
Acceptance Criteria:
Acceptance criteria should define the form and function of specific project deliverables,
establishing end-user expectations and requirements, and forming the basis by which project
deliverables are accepted or rejected. Once acceptance criteria are defined, they form a
"contract" under which the project is performed, setting expectations and creating consensus. As
such, acceptance criteria should not be changed once a project is underway unless a formal
change process is applied. Without acceptance criteria, true project closure cannot be obtained,
as there may be no specific measurement for completion. As acceptance criteria are planned, the
following questions should be considered.....
How will acceptance criteria be identified?
How will acceptance criteria be finalized?
Who must be involved in acceptance criteria definition and final approval?
How can acceptance criteria be controlled to ensure consistency and to avoid

unnecessary changes?
Closure Kick-off (timing of closure activities):

As any project is defined and structured, you will need to identify the point at which project
closure activities can begin. Typically, project closure activities should begin when project
deliverables are near completion. Overall, the goal is to ensure that valuable time is not wasted.
Once a project nears completion, transition should begin immediately in order to maintain
momentum and to ensure that sufficient resources are available to move on to the next project.
Transition (Turnover) Needs:
Depending on the type of project at hand, transition needs will vary. As you plan closure activities,
you should consider specific transition/turnover requirements. Typically, transition/turnover
activities relate to the status of project deliverables. When a deliverable is under development,
the project team is in control. Once a deliverable is ready for production, ownership must be
transitioned to end-users and operations staff so that the deliverable can be used and
maintained. Turnover planning can involve end-user training, operations training and the
preparation of procedural and technical documentation....
What types of turnover activities will be required?
How much time should be allocated to turnover?
How and when will formal turnover take place?
Who must approve and accept turnover?
Resources, Roles and Responsibilities:

As project closure is planned, resource requirements, including roles and responsibilities must be
considered. As you go through the closure planning process, think through the following
questions..
What types of resources will be required for project closure activities (considering activity
requirements, tasks, skills and responsibilities)?
Who will be involved in the closure process (including management and end-users)?
As the project draws to a close, how will project team members be reassigned to other
projects?
Who will be involved in the post project review process (to analyze project results &
performance)?
Communication:
Communication is essential to smooth project closure and transition. In order to ensure that all
parties are informed and in synch with closure activities, you will need to take appropriate steps to
keep information flowing as needed, and on a timely basis. As you plan "closure communication"
you should consider the following questions....
Will you have closure planning meetings (how many and how often)?
What types of documentation will be required to ensure effective project closure?
How will you best communicate the closure activity schedule, considering meeting
requirements, training sessions, and staff transition information.
How will formal project closure be acknowledged and recognized?
As you can see, closure activities will vary according to project needs and circumstances, but the
overall goal is constant to ensure that your project ends with success. To that end, project
closure should be recognized as a formal project process, and should be included as an
independent phase in any project plan, no matter how limited actual closure activities may be.
Entering the Closure Phase:
1. Recognize that the closure kick-off point has arrived and activate your closure plan.
2. Schedule formal closure activities.
3. Communicate the schedule to all interested parties.
4. Identify and document all remaining open issues, if any, and determine which issues
must be closed in order to obtain formal project acceptance. If needed, you can form a
post-project clean-up team to handle minor issues that do not prevent deliverables
acceptance.
5. Complete all required closure activities as needed, including production turnover, training,
staff re-allocation, and documentation.
6. Obtain formal project acceptance from customers and management.
7. Celebrate project completion with staff and end-users.
8. Complete staff performance reviews.
9. Complete the post project review process and document the results.
Conclusions:
Once the post project review is completed, your project will likely come to an official end. Certain
minor issues may linger, and the project review process may raise new issues that must be
addressed in the future. These ongoing issues can be dealt with by the project manager, or by a
post-project clean-up team, if needed. But, from an organizational perspective, formal closure
activities will bring the project to an end, freeing staff and financial resources for the next project
likely waiting in the wings.
In the busy IT project environment, projects occur at a fast and furious pace, and, at times, it may
seem as if one project just flows into the next. But it is important to take the time to acknowledge
actual project completion. Project closure is a sign of success and achievement, and should be
treated as such. In this way, you can ensure that all your projects go out with a bang, and not a
whimper.
Ideas into Action:
The Project Closure Checklist
The Acceptance Criteria Worksheet
WORKBOOK PRODUCTS....
more.
and best practices.
PROJECT SPEAK: LESSONS LEARNED

Every project begins and ends as a unique experience. By definition, projects are built upon
unique goals, with planned beginnings, foreseeable ends, assigned resources, and an organized
sequence of activities, tasks and events. Once these activities and events are completed, and the
outcome is produced or cancelled, the project is complete.
And thus, the unique experience over. Or is it?
Clearly, projects are designed to produce one-time deliverables (otherwise, they would be
called operations ). But, there is more to the project experience than meets the eye.
Projects also provide a factual basis for project and process improvement known as
lessons learned.
Every project is an experience in the execution sense, but each also provides experience in a
learning sense. On this level, every project, completed or cancelled, can be used as a bridge to
the next. When you look under the covers, you will find specific and valuable lessons for the
future. to improve performance and results. And, if experience is the best teacher, then any
activity designed to take advantage of each and every lesson offered will be truly worth the effort.
For that reason, every project should include a lessons learned review.
What are lessons learned?
In simplest terms, lessons learned are realizations about project performance. The information
gleaned can be as a roadmap for project improvement, used to maximize future successes and
minimize future failures. By their very nature, lessons learned will be based both on fact and
perception. Facts will be determined by quantifiable project results (i.e. does the deliverable
work?). Perceptions will be based on the views taken of project performance (i.e. was the
project team properly organized?).
Lessons Learned Elements
In order to take full advantage of any and all lessons learned potential, lessons must be viewed
from multiple perspectives. Projects are driven by two defining elements, the results to be
produced (product, service or process) and the procedures (i.e. management processes) used to
achieve those results. Any lessons learned review must examine both sides of this project
equation:
"Deliverables" Lessons Learned Components:
For lessons learned purposes, project deliverables (product, service or process) can be examined
according to the following elements:
Conformance to operational needs and functional requirements.
Conformance to technical specifications.
Usability and ease of use.
Alignment to intended purpose and business value.
Production quality.
Implementation quality.
Design quality.
Conformance to budget and cost expectations.
Process Lessons Learned Components:
Was the project properly defined and initiated?
Was the project properly planned and scheduled?
Were risks identified and controlled?
Was communication consistently used to keep stakeholders informed and updated?
Were resources properly utilized and allocated?
Was project progress properly monitored and controlled?
Were issues and problems tracked and resolved?
Was the budget well planned, maintained and utilized?
Did you have sufficient management support and customer participation?
Were management approvals obtained at all appropriate stages?
Was the project properly closed and transitioned?
Any review of the project management process should examine these key process elements
according to primary quality and impact criteria:
Effectiveness: Was the process used properly and as intended and required?
Relevancy: Was the process relevant to project needs?
Consequences: Did the process have a positive or negative impact on the project?
Results: Did the process produce useful deliverables (i.e. plans, documentation,
activities and/or events)?
Lessons Learned Mechanics:

The lessons learned review process is most often utilized at the end of a project, but can prove
useful at other points as well - (i.e. at the end of a phase, as a procedural audit, or at critical
points in a troubled project).
Step 1: Identify your lessons learned participants:
Who will provide lessons learned feedback?
Who will plan and conduct the lessons learned process?
Who will review and analyze lessons learned feedback?
Who will make lessons learned recommendations?
Step 2: Collect lessons learned feedback:

Lessons learned facts and perceptions can be collected via an informal or formal process
depending upon review objectives, project characteristics (large/complex or small/routine), and
available time, resources and tools. The lessons learned process can take place in an open
group meeting, via an informal one-on-one conversations, or through a formal survey process. As
the data collection process is planned, the following issues should be considered:
What deliverables and process elements must be reviewed?
How will feedback be provided?
Can the process be open and informal, or should it be closed and confidential?
Step 3: Feedback Analysis

Once the data collection process is completed, the resulting feedback data must be analyzed in
order to identify lessons learned what went right, what went wrong, and what can be gained
from each circumstance?
To that end, feedback data must be organized and analyzed to reach meaningful conclusions.
Individual and consolidated results can be viewed according to three defining categories:
Results Summary: To quantify the results produced by one or more completed surveys. What do
the results say?
Results Analysis: To evaluate the results to identify lessons learned. What do the results
mean?
Results Recommendations: To translate lessons learned into tangible performance
improvements. What happens now?
Step 4: Lessons Learned Integration
Once lessons learned are identified, and related recommendations are made and approved, the
related improvements must be applied for future projects. This is probably the most important
step lessons only have value if they are truly learned. To ensure that project and process
lessons are properly applied, the following issues must be addressed:
Lessons learned should be formally documented and approved.
Project review results should be communicated to all project participants, sponsors and
customers.
Lessons learned recommendations should be incorporated into existing (or new) project
management standards and best practices.
Conclusions:
In summary, an effective, relevant lessons learned review can offer many benefits to the busy
project manager:
To improve existing project management practices, policies and procedures.
To improve the quality and relevancy of future project deliverables.
To identify staff strengths and weaknesses, providing meaningful strategies for further
project management or technical training.
To identify outsourcing requirements for future projects, addressing resource constraints

and gaps in internal skills.
To improve technology decisions for better results in technical products and services.
To facilitate and improve future project selection strategies.
DO MORE WITH LESS: IT MANAGEMENT IN CHANGING TIMES

When economic conditions or individual business circumstances take a turn for the worse, IT
groups are likely targets for budget cuts and staff reductions. Are you prepared to do more with
less?
While staff and financial resources may be reduced, the demand for technical support will
probably not change --- if anything, it will probably increase. These circumstances demand
special tactics - information, strategy and communication.
INFORMATION:
The key to technology management in changing and perhaps, difficult times is information --- to
have a clear view of where you are and where you need to go ..
Your knowledge portfolio should include as much of the following information assets as may be
needed for your unique environment:
Technical Configurations & Inventories: you should have full knowledge of the current state of
your technical environment, including configuration and inventory information.
Current Charter: you should have a full understanding of the current IT charter - what services
are provided and how are they provided?
Business Priorities: you should have full understanding of current business priorities so that
you can adjust and align IT activities and services to ensure proper alignment.
IT Staff Strengths and Weaknesses: you should have full understanding of current staff
strengths and weaknesses. This is necessary for the consideration of revised services and
priorities, but also to weigh the impact of staff changes and reductions - voluntary or otherwise.
What is someone leaves - can you replace them? If not, how will you meet those skills
requirements?
Roles, Responsibilities and Reporting Relationships: you should have a full understanding of
current organizational issues within IT - how are required roles and responsibilities met, and how
would they continue to be met if staff changes or reductions occur?
Budget Status: you should have a full understanding of your current budget - how has it been
used to date and what is the impact of any reductions?
Service Level Obligations & Agreements: you should have a full understanding of current
service level obligations - documented or simply assumed.
Project Queue: you should have a full understanding of all projects - pending and underway.
Project priorities may have to be reviewed and changed as needed to react to staff changes,
budget reductions or changing business priorities.
Pending Problems & Priorities: you should have an understanding of all pending technology
issues and priorities - will pending systems upgrades have to be postponed, and if so, what
impact will that have on current operations? Are there any critical issues that must be addressed
to ensure continued systems performance and reliability.
STRATEGY:
Once you have a solid knowledge portfolio assembled, you can begin to develop strategies for
management under changing and challenging circumstances. These strategies need to address
the following steps and issues....
1. Assess the realities - can you still meet the parameters of the IT charter and service
level obligations in consideration of staff cuts and/or budget reductions?
If the answer is no, then you must consider alternative approaches and strategies....
2. Align IT services with current business priorities - if you have to modify service levels
and project obligations, those modifications need to suit business priorities. In this way,
IT can still be effective, even those service goals have been downsized.
3. Consider alternative methods - are you taking advantage of all procedural efficiencies,
including hardware and software tools, so that you can make the most of available time
and staff resources. This can include self help systems for end-users, systems
management utilities, or the enforcement of technical standards to minimize technical
conflicts and support issues.
4. Set realistic expectations - 24x7 support may be a lofty goal - but is it a realistic, or
even necessary? To properly set expectations and support obligations, you must be in a
position to quantify the costs of 24x7 support to the organization, contrasted with any
potential benefits. This cost/benefit analysis can help you to justify reductions in service
levels, or it can help you to demonstrate your need for additional staff resources and/or
funding if 24x7 is a true requirement.
5. Focus on systems reliability and performance - budget reductions will probably
impact new systems purchases, so you may need to take steps to ensure that all current
systems are in top working order. Keep configurations current with the latest patches
and fixes, and make sure that all configurations are fully documented to maximize
productivity for support and administrative activities.
6. Avoid staff burnout - even if staff exit options are more limited than in previous months
and years, you will still need full staff commitment and energy to get the job done. Make
sure that you consider your staff when making promises to management and end-users.
COMMUNICATION:
Once you have developed your management strategies, effective communication is a critical
element for implementation. You must have sufficient management and end-user support for any
changes in service level or project commitments, and you must also keep everyone properly
informed of related procedural changes.
Communication Tips & Tricks:
Let management know where you stand - do not be a hero. Once service levels fall or
performance problems exist, any explanations concerning staff reductions, budget cuts or
priority shifts will just sound like excuses - instead of proactive management tactics.
Don't wait for problems to surface before speaking up.
If you are in doubt about business priories - ask, never assume.
Ask for management support - let them know that you will need their backing when
complaints and conflicts arise over changing IT services and priorities.
Be thorough when communicating changes in IT policies and procedures communications should be brief and to the point, but should also include all necessary
information and explanations. And, be sure to offer contact information for questions,
suggestions and complaints.
Make sure all IT staff are informed of revised or newly adopted policies, procedures and
service levels so that you can present a united front.
CONCLUSIONS.....
As an internal support function, IT is often faced with the "do more with less challenge".... but with
some careful planning and open communication, you may be able to get through the toughest of
these times.
Ideas into Action: The IT Best Practices Evaluator
DO MORE WITH OUR SERIES OF DOWNLOADABLE PRODUCTIVITY TOOLS:
Disaster Recovery Planning...... The Disaster Recovery Plan Process Kit
Customer Satisfaction Surveys....... The IT Services Survey Kit
Workbook Product Recommendation: IT Management Workbooks are produced and published
by Right Track Associates, Inc., creators of ITtoolkit.com.
The Project Review Survey Kit ($94.95)
HOW TO MANAGE BY PROCESS - PART ONE

The Value of Process in the IT Operation
In the IT environment, results are often achieved by the fly by the seat of your pants
management methodology. Its understandable time is short, requirements change and
resources are scarce Surprisingly though, despite all this chaos, results are usually achieved.....
But what of these results? Are they the best, achieved at the lowest cost? And, how many
potential benefits were sacrificed along the way just to say issue closed, problem solved, or
project over?
To move beyond this hectic, do whatever it takes approach to IT management, you need to take
a step back and consider the value of process.
The Value of Process
A process can be most simply defined as a series of structured steps and activities used to
achieve specific management goals and deliverables. IT operations and services are particularly
well-suited to a process driven management approach.
Most internal IT organizations provide multiple services, ranging from technical support to
strategic planning. As such, this type of IT organization must be prepared to respond to multiple
business units and departments, and simultaneously serve a diverse customer base, with varying
needs and interests. This diversity demands both structure and flexibility. A pre-defined process
serves as a management foundation, providing a roadmap for service delivery.
Process can be applied at a global level to each primary element of the IT service portfolio.
Process provides a framework for service delivery, with details provided according to
individual circumstance. For example, while individual project goals, resources and
deliverables will vary, the steps and procedures used to plan and execute any project can
follow a pre-defined format, providing consistency and productivity.
Process management can be applied to standard IT service elements as follows:
Project
Management
Process defines the steps and procedures to be

followed as projects are selected, planned, managed
and executed.
Technical Support
Process defines the steps and procedures to be

followed as technical support is provided to the end-user
community. Depending on individual needs and
circumstances, these processes can relate to
outsourced support, internal technical support, Help
Desk support or other mechanisms as appropriate.
Systems
Administration and
Management
Process defines the steps and procedures used to

administer and manage systems for performance,
security, reliability and consistency.
Strategic Planning
Process defines the steps and procedures used to

collect data, evaluate alternatives, reach conclusions,
achieve consensus, and make recommendations.
Policy and Best

Practices Planning
Process defines the steps and procedures used to plan

IT management policies and best practices, which can
include asset management, disaster recovery,
technology standards, problem management and
project management.
Process Benefits:
In the IT environment, management by process provides several key productivity and
performance benefits:
Process provides a roadmap for action, eliminating the need to re-invent the wheel for
each initiative.
Process allows you to focus time and resources on issues and results, rather than the
steps needed to reach said conclusions.
Process provides a reference point for staff, allowing you to easily integrate new and
temporary staff members into ongoing projects and operations.
Process lowers production costs through improved productivity and targeted results.
To realize these benefits, every process should be structured to ensure that the following
elements are addressed:
Process Objectives:
To identify the intended purpose of the process. i.e. What will the process accomplish?
Process Workflow:
To identify the steps and activities to be followed as the process is executed considering tasks,
timelines and resource roles and responsibilities. i.e How will the process be executed?
Process Results:
To identify the expected process outcomes and deliverables. i.e. What will the process produce?
Conclusions:
Applied appropriately, the management by process methodology will yield essential productivity
and performance benefits for the busy, resource constrained IT operation. Initial process
development will take time and effort (See Manage by Process Part Two), but once complete,
that singular effort will deliver a significant return on that investment.
Related Quick Tool:
The Management Process Evaluation Worksheet
Best Practices Planning....
The Asset Management Planning Template:
A click-in-the-blank worksheet designed to help you plan asset management best practices ....
identify and document goals, requirements, policies and procedures, and calculate related costs
for tools and planning tasks.

IT alignment is an essential goal for

any information technology
organization. Technology services
must be designed to meet business
goals, vision, purpose and
strategies. Click on the links to learn
more...
Treat your end-users as strategic business partners.
Set realistic expectations for IT service goals and capabilities.
Use Service Level Agreements for customer relationship management.
Encourage and support end-user training programs.
Be proactive - take advantage of every opportunity for IT "added-value".
Pick an organizational model designed to suit IT alignment goals.
Learn how to say no to impractical service requests.
Analyze IT service metrics to find "lessons" for performance improvement.
Engage and encourage end-user participation in IT projects.
10
Take a proactive approach to manage "down-time" perceptions.
HOW TO BUILD "IT & END-USER" PARTNERSHIPS

As an organizational entity, IT can be most effective when it works in partnership with the enduser community. But these partnerships can be elusive, and difficult to build and define. This is
largely due to a natural "IT support conflict" that can exist in any organization - large or small.
As IT strives for balance between end-user demands, technology best practices, and overall
company needs, end-users tend to focus on specific, albeit important, needs of the moment ....
and so, a conflict is born....
This natural conflict may never be eradicated, but it can be mitigated through effective
cooperation, collaboration and communication. This is the essence of the IT / End-User
Partnership: to establish common ground and purpose in the delivery and acceptance of IT
services and strategies.
End-users and IT each play a part in this partnership, and to get things off the ground, these roles
need to be clearly defined and established.....
Defining the IT / End-User Relationships: The Process
Step One: Understand your needs and goals.....
Do you need to improve IT and end-user relationships?
Do IT services meet end-user needs in terms of quantity and quality?
If IT services are not meeting end-user needs, why not?

Is it a matter of training, inappropriate organization, lack of staff, insufficient quality, poor
decisions, internal politics, unreasonable expectations, or a lack of understanding and
communication?
How can the IT/End-User Partnership be used to resolve these issues and to better align
IT services and strategies with business goals and objectives?
Step Two: Identify roles.....

Who will be involved in the IT /End-User Partnership?
To be truly effective, every staff member, both in IT and throughout the business, needs to be
involved in forming and maintaining the Partnership. But, it is up to the leaders to get things
moving and to establish the framework under which the Partnership can survive and thrive .....
Depending upon your organizational size and structure, you may need to establish several
Partnership roles.....
The IT Manager
The Business/End-User Manager
The IT/End-User Liaison
Step Three: Identify responsibilities.....

The IT Manager:
This individual is responsible for the IT side of the Partnership, and must have a solid
understanding of IT capabilities, technical requirements, and business goals and objectives.
Within the Partnership, the IT Manager may have one or all of the following defined
responsibilities....
To understand the needs of the business in terms of overall objectives, and how
technology and related IT services can best meet those objectives.
To understand the internal organizational structures and how each business unit needs to
interact with IT.
To establish and maintain IT credibility through service quality and consistency.
To maintain honest communications with End-User partners regarding IT capabilities,

and not to promise more than can be delivered.
To create technology visions for the future and to ensure that these visions are
communicated effectively.
To implement and maintain an IT structure that will support this vision to the extent
financially possible.
To be supportive of IT staff and to work together with all parties to resolve internal
customer service conflicts.
To foster the Partnership amongst IT staff, making it part of performance reviews and
ongoing objectives.
The Business / End-User Manager:

This individual is responsible for the end-user side of the Partnership, and must have a solid
understanding of both end-user needs, overall business strategies, and how existing IT
capabilities fit into this puzzle. Within the Partnership, the Business/End-user Manager may have
one or all of the following defined responsibilities....
Consolidate business requirements and service level objectives so that they are
representative of actual business units as a whole, rather than individual end-users.
Clearly define those requirements to IT in clear, concise terms.
Maintain proper control over requirements so they do not change too frequently or
without tangible purpose.
Encourage adherence to internal IT policies and procedures.
Encourage participation and constructive feedback relating to IT services and strategies.
Establish channels of communication for IT service complaints.
Maintain positive relationships and cooperation during systems problems, working with IT
to mitigate damage and seek solutions.
Get involved in IT projects through Steering Committees or project team participation.
Commit to an ongoing program of end-user training.
The IT/End-User Liaison

Depending upon the size and structure of your business or organization, there may be a place for
an IT/End-User Liaison. This individual would be responsible for ensuring that the Partnership,
once defined, is maintained on an ongoing basis. Considering current economic conditions, this
may be a luxury for many organizations, but may be totally necessary for others. This Liaison
can perform several key responsibilities....
Keep communication flowing between IT and the end-users.
Uncover key business and technical requirements that may not otherwise be recognized
or communicated.
Set priorities for projects and services based on actual experiences and observations.
Monitor relationships for signs of conflict and to bring effective resolutions to the table.
Act as a mediator when conflicting needs arise.
Foster performance and productivity by allowing IT to focus more on technical strategies

and solutions than on politics and relationship management.
Step Four: Put it into action.....

Once your Partnership is fully formed, it is time to take action. The IT/End-User Partnership
should be recognized as a true business initiative, designed to maximize the usage and benefit of
technology within your organization. This requires strong management support and commitment,
and a good deal of ongoing effort.....
Begin by documenting the partnership agreement....
Put your partnership into practice through tangible actions .... have end-users attend IT
meetings, have IT staff attend business meetings, share information, invite feedback....
just to name a few ideas....
Seek upper management support for the partnership effort, emphasizing the overall
benefit to the organization.....
Keep IT operations and organizational structures aligned with business operations --- as
the business changes so must IT.
And, taking your Partnership definitions in hand, you will now need to put these principles into
practice for all elements of the IT service portfolio....
Projects
Help Desk
On site technical services
Technology policies and procedures
Technical strategies and visions
Standards, purchasing and acquisitions
Problem management
Service Level Agreements
Disaster recovery Planning
CONCLUSIONS.....
IT influence and effectiveness can be best served through a symbiotic relationship between the
end-users and IT staff - and each side needs to take an active part in establishing requirements,
defining strategies, solving problems, and recognizing opportunities.

All in one planning solution designed to collect end-user feedback for IT services. The Kit contain
information, advice, electronic survey forms, and pre-formatted "Lessons Learned" templates.
Practical advice to help you conduct an effective end-user satisfaction survey, destined to
produce meaningful results in an efficient, timely manner.
An complete process for survey preparation and administration, providing a step by step
"how-to" guide....
An electronic survey template designed and organized to collect feedback from multiple
perspectives .... service quality, awareness, priorities, and more.
An "analysis roadmap" offering guidelines and variables to help you analyze and apply
survey results.
HOW TO MAKE THE CASE FOR END-USER TRAINING

When times are tough, and budgets are tight, it gets harder and harder to justify training
expenditures. Unfortunately, it is in tough times that training can have the greatest impact, as
management looks for optimum performance and productivity in every process and system.
To justify software training costs, you will have to examine the related costs and benefits.
And, you must be able to tie those costs and benefits directly to specific business needs
and results.
This analysis begins with the identification of specific goals and objectives, as you consider these
two questions....
What problem do you need to solve?
How will training solve that problem?
What problem do you need to solve?
In order to answer this question, you have to consider needs and problems from all the essential
angles..
Are you receiving a large number of complaints from end-users regarding the timeliness
and quality of technical support?
Are you receiving a large number of repetitive, remedial support requests?
Are these support requests keeping you from completing essential projects?
Are you being asked to improve the quality and/or quantity of IT services while cutting
staff and service budgets?
How will training solve these problems?
Can end-user training reduce the number of repetitive, remedial support requests?
If these support requests are reduced, will the quality of IT support improve?
If these support requests are reduced, will you be better able to meet project deadlines
and other needs?
If these support requests are reduced, will you be able to better meet IT service demands
considering current budget and staff limitations?
NEXT STEPS
If the answer to any or all of these questions is yes, you need to move on to the next step . to
analyze training costs and benefits, and convince end-user management that training is a
worthwhile, and necessary expenditure.
Analyze Training Costs
Step 1: Identify Training Requirements
What are your training objectives (new skills or improved skills)?
Who will be trained?
How long can training last (is there a specific completion deadline)?
Is the training customized or generic? (i.e. internally developed software vs. Microsoft
Office)
Step 2: Identify Training Alternatives
What training tools and methods can apply (in-house classroom, external classroom,
CBT, distance learning, or self-study books and reference manuals)?
Can you rely on one method or a combination of methods?
Step 3: Estimate training costs considering:
Number of end-users to be trained
Volume discounts available
Fees per student (for outsourced training classes)
Development costs (internal or external)
Staffing costs (internal or external)
Facilities costs
Materials costs
Travel costs
Lost time (staff time out of the office)
Step 4: Evaluate Alternatives

Of the training alternatives considered (in-house classroom, external classroom, CBT, distance
learning, or self-study books and reference manuals), which ones will best meet training needs
and objectives in terms of:
Results
Costs
Time
Resources
Analyze Training Benefits:

Training benefits are typically realized as gains in performance and productivity, and therefore
can be difficult to measure. To quantify these benefits, you will need to answer this question:
How will training make end-users more productive, and how will that increased
productivity translate into cost savings and improved business results?
The Training Productivity Potential:
If end-users are trained for self-sufficiency in the use of computer systems and related
operational procedures, then.
End-users will spend less time spent seeking support and more time on required tasks
and deliverables.
There will be a reduction in redundant, remedial technical support requests, lowering IT

support costs.
End-users will make fewer errors and mistakes leading to faster, more reliable results.
End-users will feel better about their skills leading to improved morale and better results.
Detailed knowledge of systems functionality will lead to improved workflows and internal
procedures.
To finalize this analysis you will

need one final bit of information specific staffing costs, for both IT
staff and the end-users.
Having this information, you can
The Equation:
Training Costs vs. Training Benefits:
Increased Productivity (expressed as hours saved).
Lowered Support Costs (expressed as IT staff hours
saved)Better results (in terms of business and IT
then compare the short term costs

of training, with the long term costs
of increased staff productivity and
lowered support costs.
services).
CONCLUSIONS.....
When you present this information to management, be sure to stress results and alternatives,
showing that you have carefully considered all the angles, and are prepared to tie your training
recommendations to specific, tangible business needs. In the end, a few well placed training
initiatives can help end-users be more productive, and can also help IT do the value added work
that can truly make a difference.
MORE ABOUT IT....
CAUGHT IN A WEB OF UNREALISTIC EXPECTATIONS

How to manage end-user expectations....
Is the customer always right?
End-user opinions and perceptions are shaped largely by expectations. Quality expectations
should never be at issue. As a business imperative, technology end-users are entitled to the
highest quality of service that can be provided. High service quality usually translates into fewer
problems and higher productivity. But, in the IT services realm, quality expectations are often
confused with substance expectations, relating to the types of services IT provides, and the
means by which those services are provided. When end-users are dissatisfied with IT services,
"quality" problems are too often assumed. But, in fact, quality may not be at issue. Customer
dissatisfaction may just be the result of an expectations gap .. a quantifiable mismatch

between service expectations and service realities.
Whatever the source of end-user

dissatisfaction, IT must respond. However, the
nature of the response will vary according to
the source. If IT service quality is lacking,
quality issues must be identified and analyzed.
The resulting management response should
focus on targeted solutions, looking at staff
changes, new procedures or additional
training. On the other hand, if the reported
dissatisfaction is due to "unrealistic or
unreasonable" expectations, alternative
management approaches will be in order.
These response strategies should focus on
information, improved communication and
enhanced customer relationships.
The Expectations Gap

Warning Signs:
Do your end-users request services that are not part

of your IT charter?
Do your end-users report identified systems
limitations as error conditions?
Do your end-users feel that IT is more interested in
control than in end-user needs?
Do your end-users view necessary systems
maintenance as "outage"?
Do your end-users feel that IT is too slow to respond
to non-emergency support problems?
Do your end-users frequently claim that project results
fail to meet specified requirements?
Considering the ever-changing nature of the IT service dynamic, expectations gaps are not
unusual, but they are certainly manageable. Any approach taken to manage expectation gaps
will have three primary elements:
IDENTIFICATION: To clearly define end-user expectations for all relevant aspects of the IT
service portfolio.
ANALYSIS: To evaluate defined expectations to determine whether they are being met, and if
not, whether that failure is the result of a service problem (i.e. the identified expectation is
realistic, but it is not being met) or an expectations gap (i.e. the identified expectation is
unrealistic, and cannot be met).
RESPONSE: To develop and implement solutions and strategies to resolve any identified
expectation gaps.
Step 1: Identifying End-User Expectations:
Within any environment, end-user expectations will exist for multiple aspects of the IT service
spectrum. While specifics may vary, end-users are likely to have their own set of expectations
with regard to any or all of the following service elements:
The role of IT within the business. (service provider or strategic partner?)
The types of IT services provided.
The intended use and functionality of installed systems.
The enforcement of technology standards, policies and procedures.
Disaster recovery and business continuity capabilities.
Service level obligations (support response times, performance, reliability, availability).
Specific project terms and deliverables.
Step 2: Analyzing Expectations

The expectations analysis begins with one question . Are the identified expectations
currently being met? If the answer is "no", the analysis must continue to determine whether the
expectation in question can be met i.e. is the expectation realistic?
To determine whether an expectation is "realistic" or "unrealistic", it can be measured with the
following five criteria:
Does the expectation exceed specific end-user needs and requirements?
Is the expectation in line with overall business goals and objectives?
Does the expectation fall within operational boundaries (costs, staffing, regulatory,
contractual)?
Does the expectation fall within technology boundaries? (feasibility, compatibility and
serviceability)?
Can IT meet this expectation considering existing operational and technology boundaries,
and related limitations?
The following chart illustrates the application of this process:

THE EXPECTATIONS ANALYSIS
Expectation Description:
"IT is available to provide technical support on a
24 hour basis, 7 days per week."
Yes
Does this expectation
exceed end-user needs
and requirements?
No
Analysis
24 hour support would only be used by a

small number of end-users.
Is this expectation aligned

with overall business goals
and objectives?
Overall business goals call for the

reduction of IT support costs.
Does this expectation fall

within operational
boundaries?
24 x 7 support would increase support

costs.
Does this expectation fall

within technology
boundaries?
Is IT currently capable of
meeting this expectation?
24 x 7 support is possible with current

technologies.
IT is not currently staffed to provide 24 x 7

support.
Conclusion: This expectation is not realistic.
Having exposed these types of unrealistic expectations, you must consider the source - why do
your end-users have these unrealistic expectations.....? In all likelihood, unrealistic expectations
will arise out of any or all of the following conditions:
End-users are not sufficiently informed about IT services and systems functionality.
IT management has made promises that cannot be kept.
IT policies and procedures are not consistently enforced, creating different perceptions
based on experience.
IT services are not marketed to the end-user community.
The IT service charter has not been updated as technology changes have taken place.
Step 3: Craft Your Response

Depending upon the nature and source of your expectations gap, specific response strategies will
vary, but will always be built on the following four elements:
Communication: to share the results of your gap analysis with your end-users in order to
quantify expectations, and explain why said expectations cannot be met.
Negotiation: to find suitable alternatives to close "the gap" between expectations and
service reality.
Documentation: to record conclusions in order to avoid future misunderstandings.
Escalation: to inform appropriate management personnel when "gaps" cannot be

resolved through direct negotiation with end-users Example: if an end-user expectation
is viewed as "unrealistic" because it out of alignment with overall business goals and
objectives, IT staff may not be able to bridge that "gap". In all likelihood, these issues will
require escalation.
Conclusions:
Unrealistic end-user expectations can be a source of palpable frustration for IT staff and endusers, greatly diminishing IT effectiveness. Awareness is the first step, but it also helps to stay
ahead of the curve. As you work with your end-users to plan technology strategies, select
projects, and solve problems, make sure that related "expectations" are clearly defined and well
documented. Documentation is the key to effective "expectations management", providing a basis
for future conflict resolution, compromise and negotiation.
MORE ABOUT IT...

HOW TO MANAGE CRISIS PERCEPTIONS

Downtime happens.... hardware fails, software has bugs, and human beings, even IT
professionals, make mistakes. The real test of an IT shop is not whether problems occur, but how
often, and to what response. Problem frequency and recovery should be a matter of fact, borne
out by statistics (i.e. the server is up 99% of the time, and outages last no longer than one hour).
And logically, IT performance should be judged on that objective criteria.
But, facts do not always tell the whole story, and end-user perceptions, no matter how erroneous,
can play a large role in how problems and related IT performance are judged.
END-USER PERCEPTIONS & CRISIS MANAGEMENT
This discrepancy between fact and perception can arise from basic differences in point of view.
End-users view technology problems and service interruptions based on impact .... i.e. "I can't
work, I can't print, I can't send e-mail.....", while IT staffers tend to look at technical problems
according to cause and point of origin.
Perceptions are further complicated when technology problem events occur with some frequency
or in close proximity to one another. While IT can view each incident as separate and distinct
event, to your end-users, any individual problem can be viewed as one long string of the same
circumstance .... i.e. "this network is always down..."
The sad fact is that very few people acknowledge the norm - "as in server uptime", but they
never fail to notice the exceptions - "as in server downtime". And, distinct problems can blend
together in overall perceptions to form one massive, ongoing systems failure.
DO YOU HAVE A PERCEPTIONS PROBLEM?
This can be very frustrating to anyone who works in IT, and so, IT management must do all it can
to control and mitigate these frustrations. To start, every IT manager needs to assess the true
nature and extent of any perceptions problem with a few basic questions...
How do your end-users feel about the stability and performance of critical systems?
Confident?
Somewhat Confident?
Not Confident at all?
Does this view match the reality demonstrated by actual performance and operational
statistics?
Yes? (you have a service problem)
No? (you have a perceptions problem)
Unsure? (you have an information problem)
Obviously, any lack of confidence in systems performance is a serious problem, particularly if the
lack of confidence is justified by repeated problems and failures.
But what if the lack of confidence is unjustified?
What if your end-users believe that repeated systems problems exist even when actual
performance statistics show otherwise?
In this case, you may have a perceptions problem, which can arise from any number of
unfortunate circumstances. Perhaps you have inherited someone else's problem ... i,e. the
perception was once warranted by poor performance, and steps were never taken to mend
"fences". Or, perhaps your end-users are not sufficiently aware of all the "behind the scenes"
performance successes, causing them to focus more on what they can readily see - the failures.
When faced with these types of perceptions problems, marketing and end-user relationship
management become essential tools for the IT manager....
THE STEPS: PREVENTING PERCEPTIONS PROBLEMS
Taking action to solve problems, improve service quality and manage end-user
perceptions:
Step One: Get Started
Before you begin, be sure of your facts and ensure that your systems are as stable
and solid as possible.

Step Two: Analyze
Analyze all problem events from both points of view - technical and end-user impact.
Step Three: Identify and Define
Clearly define IT service goals, objectives and limitations for your end-user
community. It is important to minimize unrealistic expectations.
Step Four: Negotiate
Negotiate and implement realistic Service Level Agreements. This is necessary to
ensure that all parties have the same expectations regarding service obligations and
requirements, and that those expectations and requirements are clearly stated in
writing.
Step Five: Communicate
Maintain effective communications during all problem events. Give frequent, factual
updates at regular intervals, even if the news is bad.
Step Six: Be Prepared
Develop alternative operating procedures (i.e. the use of standalone software) to
minimize downtime impact.
Step Seven: Keep Information Flowing
Maintain communications event after a problem is resolved, using e-mail, memos or
formal incident reports.
Step Eight: Document, Document, Document
Keep accurate records of all critical problem and outage statistics.
Step Nine: Maintain Relationships
Maintain positive end-user relationships, watching out for any signs of negative
perceptions, warranted and unwarranted. Take immediate steps to correct problems
and control perceptions.
CONCLUSIONS:
End-users will never react well to downtime and service interruptions, but through effective
management and consistent communications, you can build sufficient credibility to weather these
storms.
Ideas into Action: The IT Best Practices Evaluator (Quick Tool)

NEW VERSION NOW AVAILABLE! In Download or Print/CD Editions...
The Disaster Recovery Plan Process Kit (Version 3) gives you the tools and resources you
need to take you from "A to Z" in disaster recovery planning. You will analyze needs, select
strategies, organize resources, write your plans and ensure plan relevancy through ongoing
testing and lessons learned analysis.
(115+) pages filled with how-to guidelines and insights to lead you through the
disaster recovery planning process, from needs analysis to DRP testing.
Quick reference Glossaries and "Planning Snapshots" to help you save time and get
a head start on the planning process.
Easy to follow project planning steps and instructions to help you plan, schedule and
monitor "disaster recovery" tasks and activities.
(3) Interactive planning forms (in PDF format) to assess disaster readiness, define
business impact, track disaster recovery planning activities, and audit DRP performance.
And, with the new data export function, you can quickly extract form data to external
applications for your own customization.
A customizable, (40) slide "project" presentation template (in PowerPoint format) to
help you kick off, manage and justify your "Disaster Recovery Plan Project".
(3) Pre-formatted templates (in Word format) to help you draft, finalize and approve
essential disaster recovery documents, including the Disaster Recovery Plan and Test
Plan. Each template includes content guidelines and auto formatting features to
streamline document production.
HOW TO CREATE IT SERVICE LEVEL AGREEMENTS

A realistic Service Level Agreement may be a key to IT success. This assessment tool will help
you to evaluate your need for an SLA, presenting key steps for preparation and implementation.
What is an IT Service Level Agreement?
An IT Service Level Agreement specifies the types of services to be provided by an IT
organization to its customers (i.e. individual end-users and business units). Service Level
Agreements can range in complexity and detail depending upon the nature of the systems
supported and services provided. In most instances, SLA's address negotiated parameters for
systems availability and performance, service quality and response times, and related end-user
obligations.
DEFINE YOUR NEEDS ....
There are any number of reasons for creating an internal IT SLA ... to establish expectations,
specify services, improve relationships and document requirements.
Looking at the list of potential reasons and benefits below, select the ones that apply to you ...
I need to quantify IT services and related organizational value.
I need to define quality in specific, (and hopefully, realistic) terms and costs.
I need to establish obligations - both for IT and the end-users.
I need to quantify the impact of poor performance and down time to the end-user
community.
I need to send a single message regarding IT services and related obligations, thereby
minimizing miscommunication and false expectations.
I need a useful tool in marketing and justifying IT services.
I need to stimulate a meaningful discussion and consideration of IT services and true

business requirements.
The items you have selected will form the goals and overall requirements for the development
and implementation of an SLA.
DEFINE SLA CONTENTS ...
What should be included in an SLA?
Naturally, SLA contents will vary by company, IT organization, services and operational
requirements. In most instances, an effective SLA should include the following information...
The types of systems and services covered under the agreement.
The start and end dates of the agreement.
A process for negotiating and implementing changes to the agreement.
The names and titles of all parties to the agreement.
The roles and responsibilities for both IT, company management, and the end-users.
Standard service times, off-hours service times, and emergency service procedures.
A process for problem reporting and escalation.
Target performance levels, response times and availability requirements.
A process for measuring and reporting on performance, availability and response targets.
The costs and charges associated with services.
A process for resolving service disputes.
RISKS & REWARDS

Every process involving clarification and commitment of IT services involves a degree of risk........
What if performance levels are unrealistic?
What if costs are too high?
What if we cannot obtain agreement?
What if we fail to meet service levels?
It is important to note that these risks can exist whether you have an SLA or not, but an effective
SLA can help you to expose these risks and hopefully, to control them. When creating SLA
terms and specifications, these issues must be considered as well.
GETTING IT DONE ....
What are the steps involved in SLA preparation and implementation?
Step One: Assess Readiness
Do you have a good understanding of service requirements and your ability to meet those
requirements with current technology and staff? If not, an SLA based on incomplete
requirements will prove ineffective, and will probably cause more problems than it solves.
Step Two: Identify Goals
Why do you need an SLA and what are you looking to accomplish?
Step Three: Document Content and Resource Requirements
What will your SLA cover and who should be involved in the preparation process?
Step Four: Negotiate and Obtain Concurrence
Finalize terms and parameters of the SLA and obtain all necessary approvals to ensure support
for the effort.
Step Five: Determine Format
Establish the format and distribution method for the SLA.
Step Six: Prepare SLA
Create the SLA document.
Step Seven: Review and Approval
Obtain final review and approval for the SLA.
Step Eight: Implement and Monitor
The SLA is put in place, and the target service levels are monitored and continually measured.
Ideas into Action: The SLA Requirements Worksheet
MORE ABOUT IT MANAGEMENT.....
positive steps towards success with a careful analysis of key planning variables. Using the pre-
formatted roadmap template, you will quickly define and document a complete project vision,
HOW TO CREATE OPPORTUNITIES FOR IT "ADDED VALUE"

Systems management and end-user support may be the "bread and butter" of the internal IT
operation, but after a while, the challenge wears off, and the best IT staff will lose interest. This is
not meant to dispute the value of those services, but to acknowledge that the most exciting,
"value-added" IT work lies beyond day-to-day operations, and into the realm of workplace
productivity and strategic planning.
That said, the road from network passwords, disk storage maintenance and help desk
calls, to strategic planning and process re-engineering can be a long, unfriendly trip. To
begin with, there is no shortage of work when it comes to managing systems and
supporting end-users. Most IT groups have their hands full on a daily basis just keeping
up with internal operations and support requests. In addition, depending on the size,
structure and nature of the supported business, IT's intrusion into strategic operations
may not always be welcome. And, end-users may not see the hidden value that lies deep
within the very technology group they rely on to reset passwords and solve connectivity
problems.
As an IT manager, if you want to get to the next level of IT influence and operation, you will have
to take the lead. To get the job done, you must meet three key objectives...
IT must be fully competent in all core operational areas.
IT must establish and maintain effective end-user relationships.
IT must seek out and exploit any and all opportunities to demonstrate visionary
capabilities through projects, service successes, and day-to-day end-user interactions.
What are your goals and interests?

So far, this discussion has been predicated on the assumption that you want to provide strategic
IT services..... you may not. Strategic services are risky, and depending on your organization,
your staff, and your current workload, there may be no percentage in sticking your neck out.
But, if you do want to provide strategic IT services, you will first need to identify your primary
goals and objectives. For example....
Do you want to provide internal consultative services?
Do you want to become more involved in project and knowledge management?
Do you want to provide process re-engineering and workflow productivity services - to

help your end-user community use existing technology to its full advantage?
Do you want to consolidate all technology decision making within a centralized IT

operation?
Do you want to act as a technology advisor - helping management make better decisions
concerning new technologies and upcoming business opportunities?
Are you capable of providing the desired strategic services....?

Do you have sufficient credibility?
Without sufficient credibility, it is unlikely that your end-users will welcome and accept your ideas
and strategic advice. IT credibility is derived from the degree of confidence your end-users have
in core IT services .... do your end-users believe that you provide quality support and systems
management services?
The Credibility Scale: give yourself one (1) point for every area in which
you have sufficient credibility with your end-users:
___ Systems reliability and performance
___ Quality and usefulness of end-user support
___ Ability to resolve problems on a timely basis
___ Quality of end-user relationships
___ Relevance of IT policies and procedures
___ Ability to complete projects
___ Ability and willingness to understand
end-user requirements
___ Timely communication of systems changes
Scoring: 0 - 3 points: low credibility
4 - 6 points: moderate credibility
7 - 8 points: high credibility
Do you have the resources and skills to get to the next level?
Without the necessary skills and staffing to provide strategic services, the desire will only take
you so far... be sure to keep your intentions, and your plans, relevant and realistic. If you do not
have the staffing, or if your staff needs training, you will first need to convince management that
your interest in providing strategic services has merit.
Do your interests match business needs?
Before you promote your plan for strategic IT services, you will those plans are in alignment with
actual business needs. Perhaps your organization is not ready, willing, or able, to accept these
services. Perhaps these services are provided in another manner (i.e. outsourcing), which you
seek to replace. In addition, you need to be prepared for any resistance you may face from end-
users, or other internal service groups, who may not be receptive to your involvement in strategic
planning.
CONCLUSIONS....
If, after careful analysis, you want to move ahead with your plan for strategic services, you will
need to take the next steps .... to stake your claim and to create the opportunity to show your
stuff....
Ensure that your systems are well managed and that all IT operational procedures are as
tight and streamlined as possible .... you will need to minimize systems problems, meet
service level obligations and ensure that your staff has the time to move on to the next
level.
Get the buy-in of your staff, making sure that they understand your goals, and are willing
and able to move ahead with you. Not every staff member will have an interest in
strategic work, and that is ok ... you will still need people whose focus remains on the
"bread and butter" technical work.
Create a mission statement to visibly document the strategic services you plan to offer
and provide.
Have your staff use their "powers of observation" to uncover procedures and operations
that can be streamlined or improved through the use of existing technology. Since frontline IT workers have a unique view of business operations, encourage them to observe
how your end-users get their work done, looking for key processes that can be improved
and simplified. Your goal is to demonstrate your ability to understand end-user needs and
to provide positive business value.
Offer to attend business staff meetings on a regular basis, to get to know your end-user
community, and learn more about business issues and opportunities to which you might
not otherwise be exposed. Look for quick successes to help you build confidence and
credibility.
Market IT services and capabilities through the use of newsletters, web sites, e-mail
announcements, training classes, and technology presentations. Use the information
gained from staff observations and business meeting participation to ensure that your
content is relevant and useful. Your goal is to keep IT continually visible and relevant, so
that when strategic issues and questions arise, someone may think "perhaps IT can
help".
Ideas into Action: The IT Best Practices Scorecard (Quick Tools)

"how-to" guide....
perspectives .... service quality, awareness, priorities, and more.
survey results.
IT BY DESIGN: HOW TO STRUCTURE YOUR IT SUPPORT ORGANIZATION

There are only two rules to follow when it comes to choosing an effective organizational structure
for your IT operation:
IT organizational structures should be created to suit business needs and strategic

technology objectives.
IT organizational structures should be created with sufficient flexibility to respond

to changing business needs and circumstances.
There is no right or wrong way to structure an IT operation, but in all likelihood, any structure you
choose will be derived from four basic organizational possibilities:
The Centralized IT Organization: In the centralized IT group, all IT management functions are
part of a single reporting structure.
The Decentralized IT Organization: In the decentralized IT group, all IT management functions
are distributed across multiple technology or end-user business units.
The Outsourced IT Organization: In the outsourced IT group, all IT management functions are
handled by external service providers.
The IT Hybrid: In the IT hybrid organization, IT management functions are delivered via some
combination of the three organizational structures described above. In reality, the hybrid IT
organization is probably the most common structure used ..... although specific applications are
wide and varied. For example, the hybrid IT group may take on any shape as needed, relying on
centralization, decentralization and outsourcing in any appropriate combination. Just consider the
following example:
Multiple Organizational Characteristics in one IT Package....
Centralized Functions: Help Desk, Networking,
Telecommunication, Standards, Security, Strategic Vision
Decentralized Functions: Project Management, Applications
Development, Purchasing, Technology Planning, Support
Outsourced Functions: Break/Fix Maintenance
Considering the possibilities, IT organizational structures should be chosen and reviewed
carefully in order to meet the needs of the business, its style, and use of technology. An "out-oftouch" IT structure will never live up to its potential, and may actually become counterproductive.
For example, if IT services are viewed as irrelevant and complicated, end-users will find ways to
work around IT, thereby defeating or diminishing key operational benefits.
Step 1: Identify business and technology requirements
Step 2: Assess your priorities
Step 3: Weigh the alternatives

Step 4: Match requirements and priorities to organizational alternatives, and operational
goals
Step 1: Identify business & technology needs according to:
Type of business
Business size and number of locations
Organizational structure
Culture and attitude
Technology platforms
Use of and reliance on technology to achieve business objectives
Business growth potential
Type of IT services required
Technical expertise of the end-user community
Step 2: Assess operational priorities: (what do you want IT to be?)
Cost focused (on lowest possible costs)
Control focused
Flexible and innovative
Responsive to best practices
Responsive to unique end-user requirements
Minimally bureaucratic
Risk averse
Risk ready
Step 3: Weigh the alternatives considering traditional organizational structures and related
pluses and minuses of each:
The centralized organizational structure offers the highest degree of "control" and
greatest economy of scale, allowing you to leverage centralized systems and IT staffing
for the entire business. Tangible advantages can be realized through enhanced
productivity, technological standardization, volume purchasing, improved, lowered
support costs, and a higher degree of consistency in services provided. However,
centralized IT groups can become overly bureaucratic, slow to respond, resistant to
change, and may appear disinterested and non-responsive when it comes to unique
end-user needs and interests.
The decentralized organizational structure is designed to focus on the technology

service needs of distinct lines of business within an organization (i.e. Human Resources
vs. Marketing vs. Sales). As such, the decentralized IT structure is usually more closely
aligned with specific and unique business requirements. As such, it is usually less
bureaucratic, offering greater flexibility and more timely and relevant service quality. On
the other hand, the distributed IT organization can be more costly and difficult to
operate, risking operational redundancies, power struggles, as well as technology
platform conflicts and incompatibilities.
The outsourced organizational structure can replace the internal "hands-on" IT

operation, with external service providers delivering core IT management services.
Outsourcing leverages vendor expertise, taking advantage of efficiencies and
experience that may be more difficult and costly to build in an internal IT shop. As such,
service quality can be improved. Depending on the service provider, individual
requirements, and contract terms, outsourcing can be cost effective, but cost benefits
may not be realized in every situation. Outsourcing usually involves a loss of
customization, independence and control, and in most cases, does not fully alleviate the
need for an internal IT operation, if only to manage and monitor the outsourced
relationship. The benefits of outsourcing will vary greatly by circumstance, vendor and
individual needs.
Depending upon its design and implementation, the hybrid IT structure may offer the
best of all worlds. Using bits and pieces of each traditional structure, the hybrid IT
operation can be organized to meet multiple needs and priorities. However, the hybrid
shop is the hardest to implement and maintain, as it takes a good deal of attention and
creativity, carrying a higher degree of risk.
Step 4: Match requirements and priorities to available organizational alternatives:

As you look to match requirements and priorities to available organizational alternatives, you will
need to carefully consider one additional aspect .... what are you trying to accomplish?
Unless you are just starting out, you are probably not working from a blank organizational
slate, and considering the frequency with which reorganizations and mergers occur, you
may even have already experienced several organizational alternatives. In order to make
efficient, effective organizational decisions, you will need to consider one key question:
What is your primary goal?
A. To create a new IT operation......
If you are creating a new IT organization, perhaps for a start-up, a growing business or as a
result of a merger, then you will likely have no direct historical reference points to draw upon ...
i.e. how was the organization set up in the past, what worked, and what didn't?
Under these exciting, but scary circumstances, whatever structure you choose, you
should be prepared to change that structure if time and circumstances warrant. To that
end, it may be wise to start out on the path of least resistance ..... with the simplest
possible structure designed to meet basic service goals, and expand as time passes. IT
organizations should be sufficiently flexible to bend as technology and business needs
change.
B. To restructure an existing IT operation.....
If you need to restructure an existing organization, you need to pinpoint your immediate goals ....
what are you trying to accomplish through reorganization....?
To lower costs
To increase workplace productivity
To downsize IT operations
To grow IT operations
To improve results and service quality
To minimize internal political conflicts
To respond to end-user complaints or problems
To respond to new business requirements
CONCLUSIONS.....
Ultimately, the internal IT operation exists to support and serve the business in the selection,
deployment and utilization of technology. The organizational structure chosen should be the one
best suited to the task, considering goals, costs, efficiency, productivity, results, and available
resources.
Ideas into Action: The IT Mission Statement Template (Quick Tools)
HOW TO "SAY NO" TO IT SERVICE REQUESTS

When your job is to support end-users or complete IT projects, it is hard to say "no" to any enduser requests that come your way. Customer service is all about helping people and solving
problems, and that implies an acceptance of any and all requests. But, internal IT services are
unique within the world of customer service.
Obviously, one primary role of the internal IT organization is to serve and support end-users, and
that involves solving problems and filling needs as requested. But IT organizations have to serve
more that just individual end-user needs, they also have to serve company interests, professional
ethics and technology best practices. For example, systems access would probably be alot
easier for end-users without pesky userids and passwords, but doing away with systems security
would certainly not be in the best interests of the company. In these types of situations, company
interests may very well take priority over end-user interests, and you may need to say "no", even
if you are technically capable of fulfilling the request.
But standards and practices are only one element to consider when you must decide to accept or
deny an end-user request..., there are also practical issues to consider:
Do you have the time to complete the request?
Do you have the resources to complete the request?
Do you have the skills to complete the request?
Do you have the authority to agree?
What are your prior commitments, and does this request present any conflicts?
Is the request within the scope of your responsibilities?
As these questions show, at times, despite the natural inclination or actual ability to be helpful,
you may need to say "no". When you must refuse an end-user request, you will want to do so
without an outright rejection - that serves no purpose and will probably only alienate your enduser, causing them to bypass you in the future or just go over your head. So the trick here is to
say "no" without actually using the word. This can be accomplished in five steps:
1. Consider the source. While it may be unpleasant, or even unfair at times, internal
politics are a reality in any business, large or small. Before you respond to any service or
project request in the negative, you need to consider "who is asking?". Sometimes, you
may not be able to "say no", even if "no" is the best response. On the other hand, an
unqualified "yes" in these circumstances can also be dangerous, particularly if you really
will not be able to fulfill the request. In these circumstances, even if you cannot say "no",
the ensuing analysis will still be worthwhile. If you are fully informed and prepared, you
can work towards compromise, and seek guidance from your own management. In
addition, in consideration of scheduling and resource limitations, every "yes" offered to
one request, may very well generate a "no" to another, so you need to be prepared to
justify and reschedule your other commitments.
2. Listen to the request. If you are to respond properly, it is important that you fully
understand the nature and the specifics of the request - does it relate to a service
problem, a project already underway, a new project or some other issue? If you refuse
the request without a full understanding of its elements and origins, you risk
embarrassment at a later date.
3. Evaluate the request. Using the questions listed above, you will need to evaluate the
request in order to determine whether acceptance and completion is possible (or even
mandatory), or to determine whether rejection is in order. Your analysis will need to
consider company policies, current priorities, available time, resources, skills and other
related issues.
4. Develop your response. Based on the nature of the request and your related analysis,
you will need to develop a response. Your responses may fit into one of four categories:
- A "yes" (you commit to the request).
- A "no" with an explanation
(I can't complete this request and here's why).
- A compromise (some alternative to the initial request).
- A referral (the name of an alternative resource for assistance)
If you must refuse the request, you should be ready to justify that decision. In this way, the
reasons for the rejection take priority over the rejection itself, placing all parties on equal footing
should the rejection be disputed. If you were to just say "no" without an explanation, it would be
very difficult to justify and defend your position. In addition, your job is to serve the business and
your end-users, if you refuse requests without viable reasons, you will likely not be in your
position for very long.
1. Offer your explanation. Once you have developed your response, the hardest part
begins .... you have to let your end-user know. How you choose to communicate your
response will depend on several factors: the nature of the request (formal or informal),
the person making the request, your relationship with that person, the sensitivity of your
response, and the culture of your company. You may choose to make your response in
person, on the phone, via e-mail, on paper, or some combination thereof. Whatever
mechanism you use, you should always follow a few basic techniques:
1. Don't be defensive or overly apologetic. Simply state that you regret that you cannot
complete the request at this time, and offer your explanation. (i.e. scheduling conflicts,
conflicts with internal policies, conflicts with other plans or projects, etc.) Emphasize the
reason, not the rejection.

2. Try and be as positive as possible, focusing on any compromises or alternatives that you
can offer.
3. Always leave yourself an opening for a graceful exit. Your end-user may offer an
alternative of their own, point out an error in your analysis, or they may react negatively to
your response. If necessary, leave yourself a way to "re-think" the matter so that you can
seek assistance from your own management before things get ugly. You can accomplish
this with a simple statement to the effect of "if you have any questions, or feel that I have
misunderstood your request in any way, please let me know". Let the end-user know that
you have not shut the door in their face.
HELP YOURSELF:
There is no doubt that the act of refusing an end-user request can be difficult and stressful,
requiring the right combination of communication and interpersonal skills to carry it off. But you
can also take proactive steps to make the process easier....
1. Seek advice and guidance from your manager whenever necessary. At the very least, it
is wise to give your management a "heads-up" if a problem, (i.e. an unhappy user), is
headed their way. In addition, there is no reason to take the burden of a difficult decision
on your own shoulders if you don't need to.
2. Set structured procedures and formats for the submission of end-user requests. You
may be surprised how the quality and quantity of requests will change when such
requests have to be in writing, and have to be approved by management before
submission to IT. In addition, if you establish and enforce a structured process for enduser requests, you will likely minimize the type of ad-hoc "grab you while walking down
the hall" requests that are easy to forget, and are bound to get you into trouble. While
your end-users may resist, with a bit of effort, it is easy to justify a structured request
process as a means of improving IT services.
3. Get yourself and your IT group as organized as possible so you make the most of
available time, and can schedule and prioritize your workload effectively.
In short, the nature of customer service is to serve, and it is never easy to say "no". But the
challenge in IT is to balance the need to serve multiple end-users, with the need to meet overall
priorities and serve company interests. Sometimes a "no" is necessary to meet that goal.
HOW TO ANALYZE IT SERVICE PATTERNS & DEMOGRAPHICS

Within the IT environment, there is often a great deal of attention paid to service statistics as an
indicator of IT performance ... i.e how many support requests are received, how long does it take
for IT to respond, and how quickly are these requests are closed.
These are all important concerns, but they should not be the only concerns. IT service quality
and value should not be measured merely by the numbers. To begin with, numbers can be
deceptive. Just because support requests are "closed", that does not necessarily mean they are
"resolved" to everyone's satisfaction. IT is supposed to provide value within an organization, and
value is not achieved simply because a majority of support requests are closed within a short
period of time. Technical service requests are often complex and multi-layered, and a problem
report may not be an actual problem, but rather a need for additional training or further
information. In addition, when IT service requests are viewed only as individual, discrete events,
important trends and patterns can be missed. Therefore, when evaluating IT service statistics, IT
managers need to look beyond the numbers and into the hidden meaning.
To that end, service statistics should be reviewed and analyzed from three perspectives.....
1. Request Demographics: to identify basic service request information.
2. Request Patterns: to identify trends and commonalities.
3. Process Patterns: to uncover potential problems in IT response processes and service
quality.
REQUEST DEMOGRAPHICS:
What do your IT service statistics tell you about.....?
The number of support requests received.
The individuals requesting support.
The type of request (i.e. problem report, "how-to" question, general information,
password reset, purchasing request, etc.).
Specific systems involved.
Service gaps and exceptions.
WHAT DOES IT ALL MEAN? ANALYZING REQUEST DEMOGRAPHICS.....
Are you getting the expected number of requests considering the size of your
end-user community? A low number could be indicative of a well run operation, or, a
lack of confidence and awareness of IT services. A high number could be indicative of
a problem environment, but a well recognized IT operation (i.e. your end-users know
where to go to get help, the question is, why is so much help necessary?)
Do you tend to get support requests from the same individuals repeatedly, or do
you receive requests from a balanced portion of your end-users? If you receive
repeated requests from a limited set of end-users that may be indicative of a need for
targeted training for those end-users, as well as a need for a broader sphere of IT
influence (i.e. why is IT service utilization so limited?)
What is the most common type of request received? Do you receive more of a
certain type of request than for others? A concentration of requests by type may be
indicative of a need for improved training, communication, or additional "how-to"
information.
Do you receive more frequent service requests for a specific system than for
other systems? A concentration of requests according to system type may be
indicative of a technical problem with respect to that system or a specific training
deficiency with respect to that system.
Are there any obvious gaps or exceptions found in your service statistics? (Do
you receive all the types of requests you would expect to receive based on the systems
in use and the level of end-user sophistication?) A lack specific IT service requests may
show that certain systems are not being used, that end-users are not sufficiently
informed of specific systems functionality, or that alternative sources of support are
being used.
REQUEST PATTERNS:
Can patterns be detected in support requests according to....?
Business department
Job Functionality
Physical location
Time of day
Day of the week
Specific month
Corresponding conditions
WHAT DOES IT ALL MEAN? ANALYZING REQUEST PATTERNS
Request patterns are used most often to pinpoint and identify problem commonalities
for the purpose of tracking and resolving long standing or recurring problems. As you
analyze the patterns found within your service statistics, you can consider the following
questions....
To detect physical trends: Can problem patterns or trends be isolated to a
given department, job function or location? If so, problem trends may involve
physical elements unique to that given location (i.e. cabling) or unique to the
way a system is used within a given job function or department.
To detect timing trends: Can problem patterns or trends be isolated to a
particular time of day, week or month? If so, problem trends may relate to
peak systems utilization or capacity issues.
To detect operational relationships: Can problem patterns or trends be
associated with specific operational conditions? For example, do certain type
of support requests occur more often when other operational activities are
involved such as excessive printing, backups, or month-end closings?
PROCESS PATTERNS:
Can patterns be detected in the way support requests are handled according to.....
An adherence to established support procedures.
An adherence to service level objectives.
The number and source of service complaints.
The number of request escalations.
WHAT DOES IT ALL MEAN? ANALYZING PROCESS STATISTICS
The analysis of IT service process statistics can be used to identify and isolate potential
problems in the delivery of IT support services.
Are the majority of IT service requests submitted by end-users in

accordance with established procedures? If not, what is the potential
reason .... a lack of information or are service and support procedures
inappropriate?
Are the majority of support requests handled by IT staff according to
established procedures? If not, what is the potential reason..... a lack of
training, or are the procedures inappropriate?
Are the majority of support requests resolved within established service
level standards? If not, what is the potential reason .... the standards are
unrealistic, a lack of training, or insufficient staffing?
How many service complaints are received and how does the number of
complaints compare with the total number of requests? If the number of
complaints is too high relative to the number of requests, what is the potential
reason .... poor service quality, insufficient customer relationship
management, or unreasonable service expectations?
Can patterns or relationships be identified between service complaints
received and type of request, the individual submitting the request, and
the way the request was handled? Do you have a higher number of service
complaints when specific systems or people are involved?
Are the majority of support requests handled by the responsible
organization? If not, are organizational boundaries being bypassed because
of poor service quality, a lack of information, or internal politics? Are
organizational responsibilities allocated on a logical and functionally
appropriate basis?
How many support requests are resolved at "first-level" support, and
how many are escalated? If the number of requests resolved at first level
support is below expectations, what is the potential reason .... a lack of
training, a lack of information to solve problems, or ineffective staffing?
Next Steps: Applying Analysis Results
As IT service statistics are tracked and analyzed over time, hidden meanings will become clearer
and easier to identify. Once these meanings are uncovered, appropriate actions must be taken to
resolve any related issues and problems....
Technical patterns should be investigated and tested to uncover potential problems in
terms of performance, operation or capacity.
Additional training should be provided to respond to obvious knowledge gaps on the part
of the end-users. These knowledge gaps may be the source of otherwise unnecessary
support requests.
How-to and self-help capabilities should be provided to the end-users to respond to
information gaps. These information gaps may be the source of otherwise unnecessary
support request.
IT policies and procedures should be documented and distributed to ensure that endusers are fully informed on relevant processes (i.e. how to request support, technical
standards, security policies, purchasing procedures, etc.).
IT service procedures should be reevaluated to ensure appropriate alignment with

organizational characteristics and business needs.
THE IT JOB SEARCH: UNCOVER IT IDENTITY

In a job interview, you can be judged just as much by the questions you ask, as by the answers
you give. Each question is an opportunity .... to make an impression, and to uncover key
information.
Obviously, you need to address the interview basics .... job responsibilities, potential for career
growth, and reporting relationships. But you should also take the time to dig a bit deeper to
uncover organizational "IT Identity".
WHAT IS IT IDENTITY?
IT Identity is defined by the operational structure, culture and attitude of a technology
department. While IT Identity is usually not documented in the employee handbook, it can
significantly impact one's ability to succeed in an organization. Not every company approaches
technology management in the same way and it is wise to consider the impact that
organizational structures can have upon the individual, even in the largest corporation.
A PRACTICAL PROCESS:
Whenever you are in a position to find or change jobs, consider the following questions as you
evaluate potential employers:
Is the company's IT organization centralized or decentralized?
For example, do all departments and operations report through to a single CIO or director? Or,
is the organization distributed, reporting to separate technology units or lines of business?
If centralized, how is the organization structured in terms of technologies supported and
operations performed?
Are there separate departments for the design and delivery of technology?.... infrastructure and
telecommunications management?... network support and operations?.... Help Desk?....
custom application development?... or project management? If technologies and related
functions are separated into different units under one IT umbrella, how do these units work
together when functional or operational integration is required?
If decentralized, how does the organization deal with conflicts in common, and perhaps
competing functions?
As an example, if technology decisions and support are distributed across business lines, how
are decisions made for shared infrastructure, purchasing or platform standards?
If the company has multiple locations, what is the role of the technology organization in
remote sites?
If assigned to a satellite location, what role would you play in key technology decisions and
operations, and how would you interact with other sites?
How long has the current structure been in place, and what has been the pattern of
change?
Constant change is common in business, and certainly in technology. As a result, you can
expect IT organizational change to occur, the main question is how often, and in what direction?
If past is prologue, the historical pattern of change can be critical to anticipating long term IT
identity.
IF THE ORGANIZATION FITS......

Making career choices?... try looking at an organization from all the angles......
The size and structure of the company and it's technology operation.
The specific technologies managed and supported.
Relationships with vendors and outsourced services.
The degree of technical innovation and flexibility.
The current state of technology platforms (up to date or in need of repair?).
The existence of working operational policies and procedures.
The relationships (positive or adversarial?) between IT and the
end-users.
On call requirements - is IT 24 x 7?
The work culture - dress code and office surroundings.
CONCLUSIONS....
Match company IT identity with your own.....
Once you have examined organizational characteristics, you will need to compare those
characteristics with your own interests. As you go through this next exercise, consider the
following questions:
What are your overall career goals - do you want to be involved in the design and
deployment of technology, or in the management of technology operations?
Do you want to be a "big fish in a little pond" or to play a role in a large corporate
environment? The corporate environment may provide exposure to a more sophisticated
range of technology. On the other hand, you may be able to play a more strategic and
influential role in a smaller company.
Do you work best in a team, or as an individual, and do you feel more comfortable with
ongoing, specific work assignments, or varied work assignments?
Do you seek further development of experience and skills you already have, or to make
changes in a new direction?
Do you feel at ease with corporate politics and bureaucracies?
Are you interested in a specific area of technology?
BUILD YOUR PORTFOLIO OF PRACTICAL MANAGEMENT SKILLS....
Real world experience in a download.....
HOW TO USE OF E-MAIL FOR BUSINESS COMMUNICATION

E-mail is a great tool for business communication.... it's accessible, fast and relatively easy. But,
under certain circumstances, e-mail can also be ineffective and inappropriate. At one time,
written business communications were limited to physical memos and letters. Somehow, when
words were put to paper, they were granted a certain degree of respect - whether they are being
written or being read.
To a large extent, e-mail has changed all that. Information and thoughts once carefully crafted on
paper are now quickly transcribed and distributed via electronic mail. Obviously, e-mail has many
advantages -- timing, reach, cost and speed. These advantages are hard to ignore, but under the
right set of circumstances, these very advantages can work against you.
Communication is a combination of art and science. The art of communication is knowing what to
say, when to say it, and how to say it. E-mail provides you with the physical means of
communication, but you still need to ensure that your message is conveyed properly. And
despite all of the advantages, e-mail may not always be the best choice. Consider the issues....
Electronic mail may be considered too "casual" or informal for certain types of
communication, diminishing the value and impact of your message.
Electronic mail may be over-used and over-distributed, and you may lose attention in
overcrowded mailboxes.
Electronic mail may be inappropriate for messages of an overly sensitive or confidential
nature. For example, you should probably avoid coaching staff members on performance
issues via e-mail. Or, in consideration of internal privacy and e-mail retention policies,
you may need to avoid e-mail for certain matters and situations.
Electronic mail may not be equally embraced by all. You need to consider internal
attitudes and "corporate culture" - i.e. how is e-mail used within your organization? If
your communications choices are out of synch with company outlook and attitudes, your
messages may never hit their intended goal and purpose.
In short, a series of poorly written, poorly placed e-mails can have a negative impact on your
career - diminishing your influence and credibility. However, you can hardly afford to waste time
(and paper) on physical memos when e-mail would be far more timely and appropriate. Nor
should you call a meeting when an e-mail will suffice. To make the most of your electronic
communications choices, you need to carefully consider needs, goals, and available alternatives
....
The E-Mail Evaluation Checklist
Use the following list of questions to assess your communications needs, and to determine if email is a viable mechanism for the message at hand....
Audience: consider the following questions...
Who is the intended audience?
What is your relationship with that individual or group of individuals?
How is this audience likely to view e-mail as a means of communication?
Are there multiple recipients?
Are there multi-level recipients (i.e. primary recipients, carbon copy recipients, and blind
carbon copy recipients?
Is it possible that the message will be forwarded to others you may not know?
If so, is this something you need to avoid?
Is e-mail the best choice for communicating with this audience?
Purpose: consider the following questions....
What is the purpose of this communication - i.e. to disseminate information, to make a
request, comment or suggestion, to offer a thank-you, or some other purpose?
Is e-mail the best choice for this intended purpose?
Topic and Timing: consider the following questions....
Is the communication of a sensitive or confidential nature?
Can the message be properly conveyed via the written word?

How should the message be crafted to avoid misunderstandings?
Should this communication have a formal or casual tone?
How are other communications of a similar nature normally sent?
Are there any internal policy requirements precluding the use of e-mail in this case?
Is the message urgent?
Is the message necessary?
Can the timing requirements only be met with e-mail?
What impact will this communication have upon the recipients (i.e. is this good news or
bad news?)
Is e-mail the best choice for these topic and timing requirements?
Content and Format: consider the following questions....
How should this e-mail be constructed in terms of content and format?
How lengthy will the message be?
Should the message include text, or text, graphics, fonts, links, and other elements?
What standards should be applied in terms of carbon copies, blind carbon copies, subject
lines, and labels (urgent, confidential)?
Is a formal response required, and what instructions should be given for the timing and
submission of any required responses?
Is e-mail the best means for conveying this content, in the required format?
The Final Analysis:
This e-mail evaluation should answer one bottom-line question -- is e-mail the best means for
creating and distributing the message at hand, considering the audience, purpose, topic,
timing, and content? If you feel that e-mail is inappropriate, you should consider the
communication alternatives, which can include a face-to-face discussion, formal meeting, memo,
letter or phone call.
If e-mail is the way to go, then stick to the requirements uncovered in your evaluation analysis.
And, above all, make sure your e-mail is well written, grammatically correct, and spell-checked.
As a business tool, e-mail carries more than mere words and images - it also conveys distinct
impressions, with the power to enhance or diminish your reputation, acceptance and credibility. It
has been said that you should "dress for the job you want, not the one you have". Along these
lines, it can be said that you should use your e-mails for the level of influence and respect you
want, not the level you have.
MORE ABOUT IT MANAGEMENT:
HOW TO MARKET THE HELP DESK OPERATION

Help Desks exist for one primary reason - to assist end-users with technology. This assistance is
not provided as a perk - but to ensure the effective use of technology ... for optimum productivity
and ROI.
Theoretically, if there is a need for an internal Help Desk, and that same Help Desk is not being
fully used, then the end-users are probably turning elsewhere for support ... perhaps to coworkers, or other external resources. These alternative support mechanisms can easily translate
into lost productivity, added costs, or a diminished control over technology assets and decisions.
As such, the Help Desk organization has an obligation to market its services to the enduser community. This marketing effort should not be designed solely for job security
(although that can be a benefit), but to generate interest and enthusiasm for the services
that the Help Desk has to offer. An effective marketing program should provide useful
information regarding the role of the internal Help Desk, and related service programs..
ASSUMPTIONS:
Before you can begin an effective marketing program, you should first clear a few basic
assumptions that could stand as obstacles to effective marketing ...
Assumption #1:
Your Help Desk is prepared to deliver on any and all obligations relating to services provided and
offered. You will lose credibility very quickly if you promote something that you are not prepared
to deliver.
Assumption #2:
Your Help Desk services are designed in accordance with the needs and requirements of your
organization and the end-user community. If your charter misses the mark, or service quality is
poor, marketing will do little to encourage end-users to take advantage of help desk services.
Assumption #3:
You have management support, both for the marketing effort, and for the Help Desk itself as a
strategic business partner within the organization. Without this management support, you may
first need to market the Help Desk to company management before you start on your end-users.
SET YOUR GOALS ...
What is the purpose of your marketing program and what do you hope to accomplish?
Increased utilization of Help Desk services.
Improved understanding of Help Desk policies and procedures.
Open lines of communication between the Help Desk staff and the end-users.
Improved relationships between the Help Desk staff and the end-users.
Improved awareness of service level obligations to establish realistic expectations.
Improved morale for Help Desk staff members.
Reduction in "hidden" support costs.
Maximized workplace productivity through the adherence to chosen technology
standards, policies and procedures.
MARKETING TECHNIQUES:
Create a Help Desk Services Handbook to be given out to all employees (to be included as part
of any new employee orientation). Depending upon the setup and charter of your Help Desk, this
handbook can include any or all of the following information ...
Help Desk Charter - goals and mission statement.
Help Desk Organizational Chart - management, number of staff and reporting
relationships.
Logistics - physical location, hours of operation.
Service Menu - listing services provided and technologies supported.
Policies and Procedures - help desk processes, how to submit a support request, how
calls are handled , assigned, escalated and closed.
Service Obligations - response times, problem escalation path (with a reference to any
Service Level Agreements that may be in place).
Produce a Help Desk Services Newsletter - to be created and distributed on a regular basis.
Depending on your needs and technical resources, this newsletter can be produced in paper or
electronic format, and can include any or all of the following information ...
The latest technology updates and changes.
Changes to Help Desk service programs.
Technical tips and tricks.
Upcoming events ... training classes, scheduled network or systems maintenance,
systems upgrades, new product rollouts.
Known bugs, problems and related workarounds.
Security alerts and advisories.
Help Desk Staff announcements (i.e. promotions, new hires, staff member of the month).
Statistics (if they are good) - the number of calls received, wait times, calls closed, and
any improvements over time.
Success stories and customer testimonials.
Launch a Customer Satisfaction Survey program ....
Randomly survey end-users immediately after Help Desk services have been used to
determine the level of satisfaction with individual support occurrences.
Conduct a regularly scheduled customer satisfaction survey to gauge global impressions
of Help Desk quality.
Provide a useful method for end-user feedback - i.e. a suggestion box.
Increase Help Desk visibility ....
The Help Desk manager should interact with end-users directly, perhaps by attending
unit staff meetings.
Offer tours of the Help Desk center/work area to the end-users.
Improve relationships with other IT groups, perhaps rotating staff to short help desk
assignments so that other network engineers, design staff, programmers and project
managers can see how the "support half lives".
Ideas into Action: The SLA Requirements Worksheet (Quick Tool)
The IT Services Survey Kit NEW VERSION!
"how-to" guide....
perspectives.... service quality, awareness, priorities, and more.
survey results.
THE BASICS OF IT MANAGEMENT "POLICY AND PROCEDURE"

Policies and procedures - oh no! Let' s face the facts, policies and procedures are often seen
through negative eyes, commonly viewed as an administrative burden, designed to limit creativity
and impede the need to "just get things done". And in fact, IT management policies, and related
procedures, are often used to limit and control technology utilization, lower operating costs, and
to limit risk exposure (financial, security, and otherwise).
From this perspective, policies and procedures are a necessary, and at times, intrusive, means to
an end. However, the story does not have to end there. When used effectively, "policy and
procedure" can also be used as a promotional tool, to maximize the use of technology and IT
related services. Effective policies and procedures can enhance productivity, minimize redundant
work effort, and promote consistency in performance and results. When policies are defined,
decisions can be made with greater confidence and independence. When procedures are
defined, internal and external staff can act with greater certainty and self-reliance. The key is
alignment ... to create and apply policies and procedures designed to match business goals and
objectives.
What are policies and procedures?
Policies and procedures are distinct entities, used in tandem to drive IT operations, strategies and
decisions. As management terms, they are often used interchangeably, but in reality, policies
and procedures are not one and the same.
Looking at policy......
Policies are specific statements of principles and strategy, providing a "what and why" basis for
consistent planning and decision making. Policies can be implied (action becomes policy) or
expressed (policy drives action). Implied policies may not exist in documented form, but they
become part of the operational culture through repeated patterns of planning and action.
Expressed policies are created through detailed planning, and are applied through formal action.
In any practical work environment, implied and expressed policies will co-exist.
Looking at procedure......
Procedures provide the actionable steps and activities needed to translate ideas into action. By
definition, procedures are always expressed, laid out as a series of steps and activities to be
executed for a specific purpose and in a specific order. Procedures support policies, but can also
exist without a corresponding policy entity.
The chart below illustrates the practical distinctions between "policy" and "procedure" .....
Application
Purpose
Content
Maintenance
Policy
Broad
Procedure Targeted
What & Why?
Concepts &
Guidelines
Infrequent
Changes
How, When &

Who?
Steps &
Workflows
Continual
Updates
How are policies and procedures used in IT?

Within the IT environment, policies provide the guiding principles upon which operations and
services are based, and procedures provide the actionable steps and activities needed to support
said policies (whether express or implied). As a management tool, IT policies and procedures
exist at two levels:
Internal: Policies and procedures used within the IT operation to maintain and provide
systems and services.
External: Policies and procedures followed by the end-user community as IT systems
and services are utilized.
In fact, these levels often co-exist within a single policy or procedure. For example, an individual
security policy will contain components for internal IT staff, (as a guide to technology design and
installation planning), and for end-users, (as a guide for secure computing within the business
environment).
While details will vary based on business and technical needs, any IT "policy" portfolio will likely
contain the following elements:
Acceptable Use Policies: Setting guidelines for the implementation and usage of enduser technology, including individual computers, networks, internet, intranet, e-mail,
voicemail, telecommunications and related systems and services.
Security Policies: Setting security guidelines for individual computers and shared
systems, including network access, data usage, access, retention, and confidentiality,
passwords, virus protection, remote access, and physical security. (see Data Security
Policies)
Disaster Recovery Policies: Setting guidelines for disaster recovery and business
continuity practices and procedures.
Technology Standards Policies: Setting guidelines for the selection and
implementation of technology standards, determining the type of systems and services to
be utilized within the business organization, including product selection, acquisition,
installation, and disposal. (see End-User Technology Standards)
Service Related Policies: Setting guidelines for the development and delivery of IT
services, including installation, support, maintenance, project management, strategic
planning and training.
IT Organizational Policies: Setting guidelines for the creation of the IT organization,
including the IT mission, roles and responsibilities, organizational structures
(decentralized vs. centralized), organizational authority, staffing structure, and service
goals. (see IT Organizations by Design)
IT Operational Policies: Setting guidelines for the execution of internal IT operations,

including systems administration, change management, systems configuration, technical
design, product testing and evaluation, software development and related operational
services.
On the other side of the coin, procedures must follow policy, in order to ensure that strategic
guidelines and decisions can be translated into tangible action. Depending upon policy specifics,
any comprehensive procedural portfolio will contain the following "how-to" elements:
How to use end-user technology (in support of acceptable use policies).
How to access, categorize and store data, use passwords, virus protection software, and
ensure physical security (in support of security policies).
How to respond in the event of a technology related disaster (in support of disaster
recovery policies).
How to purchase, install, configure, relocate and dispose of hardware, software and
related technology systems and services. (in support of technology standards policies).
How to request technology related services, including support, maintenance, and project
requests. (in support of service related policies).
How to assign and execute IT roles and responsibilities. (in support of organizational
policies and procedures).
How to perform operational tasks, including installation, administration, configuration,
testing and related activities. (in support of operational policies).
Conclusions:
When used in effective combination, policies and procedures can provide the "informational"
foundation upon which technology decisions are made and services are delivered. To be more
than just an administrative exercise, policies and procedures must be an accurate reflection of
business needs and objectives. As a result, effective policies and procedures must be developed
through a careful process of planning and analysis.
Fourteen Questions to Consider:
What is the current business need (i.e. problem to be solved, or
improvement/advancement to be made)?
How can policy and/or procedure be used to meet this need?
How will any new policies and/or procedures be applied within the organization (i.e. to the
entire organization or specific departments)?
What is the expected life span of any new policies and/or procedures (long term or short
term)?
How will the current organization be impacted by the implementation of any new policies
and/or procedures?
Will there be any negative consequences from the implementation of any new policies
and/or procedures?
Will there be any internal or external resistance to the implementation of any new policies
and/or procedures, and if so, how can this resistance be overcome or mitigated?
What is required format for any new policies and/or procedures (formal, informal, paper,
electronic)?
How will any new policies and/or procedures be developed (in terms of tasks, time and
resources)?
Who will have input into the development of any new policies and/or procedures?
Who must approve the development and implementation of any new policies and/or
procedures?
How will any new policies and/or procedures be introduced and communicated within the
organization?
Who will be responsible for the implementation and maintenance of any new policies
and/or procedures?
How will any new policies and/or procedures be evaluated for success?
Related Reading and Tools:
Policies and Procedures: Documentation Building Blocks
The Policy Evaluation Worksheet
INTERNAL CUSTOMER SERVICE: 5 KEYS TO SUCCESS
The customer must be served! But in the context of internal services, just who is the
customer and how are they best served? In a traditional sense, a customer is any individual or
group receiving company goods and/or services. In the "internal" sense, the customer receives
goods and/or services, but the exchange occurs within the logical confines of the organization ....
the customer and the provider are both "employees".
"Dependency" is a key element of this internal service relationship. Internal customers depend
upon internal service providers to get their own jobs done. Traditional "internal" service providers
include Human Resources, Legal, Accounting, Purchasing and of course, Information Technology
departments. In the IT context, the "services" menu is varied, encompassing systems
management, design and implementation, programming, technical support, training, break/fix
hardware maintenance, strategic planning, and project management. Each of this services can
be deployed in varied combination to support company goals and objectives, and to help
company employees fill their assigned tasks and responsibilities.
What is customer service?
According to the Wikipedia online encyclopedia, customer service is defined as "the set of
behaviors that a business undertakes during its interaction with its customers". From an
internal service perspective, this definition can be broken down into four components.
Business = The IT department (or related organizational entity) providing the services.
Interaction = The various services provided (also known as the service portfolio).
Customers = The individual end-users and departments receiving the services, and the
company (employer) for which the services are performed.
Behaviors = The "manner" in which the services are provided considering quality,
effectiveness, timeliness, efficiency and performance.
Does customer service = customer satisfaction?
Not necessarily. In a traditional "external customer" sense, customer service is often defined by
customer satisfaction, or the lack of customer complaints. In the internal services sense,
customer satisfaction must go beyond "our end-users love us". As noted above, internal IT
service providers answer to multiple "customers", and, as luck would have it, these customers
often have conflicting interests. Taking human nature into account, it is impossible to keep all the
customers "satisfied". Therefore, effective customer service planning and management must
take all variables into account. To survive politically, the customer must be kept "reasonably
satisfied", as business needs are met, costs are managed, and conflicts are balanced.
In this respect, customer service planning should be guided by business needs and quality
principles, as found in the five keys for customer service success:
The 5 Keys of Customer Service Success
Service Alignment
Service Standards
Internal
Communication
Customer Service
Commitment
Continuous Service
Improvement
#1 Alignment: IT services must be suitably relevant and "aligned" with business needs and
objectives. Each service provided should meet a defined purpose, and should be clearly defined
by the expected "return on investment".
#2 Standards: Clear "standards" should be set for service delivery, covering service quality,
timeliness and overall performance. Standards are used to determine "how" services are
provided, as well as how service conflicts and problems are to be resolved.
#3 Communication: Service "specifications and expectations" should be clearly communicated
to the customer community as needed to ensure that all parties are fully informed.
Communication tasks and deliverables can include training, "internal" marketing programs,
newsletters, and Service Level Agreements, as well as a defined process for customer
satisfaction feedback.
#4 Commitment: Service "staff" should be trained and tasked with an appropriate commitment to
customer service principles. To achieve this required loyalty and dedication to customer service,
both parties must accept shared obligations to the process, and full accountability must be
established. Customer service should be part of the "service" performance evaluation, and
management personnel should continually enforce and support all "service oriented" practices.
#5 Continuous Improvement: Service performance should be continually measured against
defined metrics to pinpoint problem areas and improve service offerings. Improvement must be
based on the verifiable analysis of measurable results, including actual performance metrics and
customer satisfaction feedback, Please note: Internal "customer" complaints do not
automatically signal customer service failures. In the IT environment, customer complaints are to
be expected, particularly when resources are constrained, and overall business interests take
precedent over individual needs. In this case, quality customer service will be defined more by
your ability to respond to, and resolve complaints through negotiation and compromise.
The Customer Service Plan
There is a wide gap between a theoretical desire for a "customer service" driven IT program, and
the actual implementation of said program. The all too prevalent "just get it done" attitude often
conflicts with a true customer service orientation, where style and substance are given equal
weight. "Customer service" methodologies will add "overhead" to the service process. As such,
customer service programs must be "sold", and the effort begins with the Customer Service Plan
(CSP). The CSP differs from a Service Level Agreement in its focus on "mission" rather than
specific services.
Preparing the Customer Service Plan:
Identify CSP scope (covered customers and services). CSP scope can be defined
through the following questions:
Business = Who is provided the services covered under this plan?
Interaction = What services are provided under this plan?
Customer = Who will receive the services provided under this plan?
Identify CSP goals and objectives. i.e. What is the purpose of this Customer Service
Plan?
Identify CSP parameters according to the (5) elements of success....
Alignment - How are the covered services aligned with business needs and objectives?
Standards - What are your standards for customer service with respect to
quality, courtesy, efficiency, timeliness, cooperation, problem escalation and
overall performance?
Communication - What communication methods will be used to ensure that
customer standards are met? Customer service communication begins with the
CSP, and can be expanded as needed though newsletters, meetings, training
programs, and related information.
Commitment - How will commitment to customer service be established and
maintained?
Continuous Improvement - How will continuous improvement be established
and maintained?
Conclusions.....
Internal customer service is a complex process, filled with contradictions, constraints and
caveats.
Internal services are too often viewed solely from a "cost" perspective, and benefits are
too often ignored and minimized.
Customers (individuals and departments) can have competing interests, and it may be
difficult to create a "one size" fits all service portfolio.
Customer satisfaction demands may be in conflict with "global" organizational interests
and "service" best practices.
These conflicts and contradictions can be addressed with a blended "customer service"
approach, where "internal services" are viewed as a component of external services... i.e.
"Internal customer service improves external customer service through productivity, quality,
efficiency and employee satisfaction". To sell this customer-service approach to IT service
management the following questions must be addressed:
How will the intended Customer Service Plan be used to ......
Deliver company goods or services?
Deliver quality customer service?
Meet company goals and objectives?
Meet regulatory requirements?
Improve productivity, efficiency and quality?
Lower operational costs and expenses?
Internal services can be "sold" to company management using this marketing perspective,
showing how these varied services contribute to the bottom line, improving products, services
and productivity.
Ideas into Action:
Customer Service Plan Template

TOOLS FOR CONTINUOUS PERFORMANCE IMPROVEMENT:
Continuous improvement in "customer service" performance relies on the collection and analysis
of multiple pieces of information, including actual performance metrics and customer
"satisfaction" feedback. ITtoolkit.com offers (2) specific products to help you collect, organize,
and analyze customer feedback for projects and IT services. Just click on the links below to learn
more....
HOW TO PLAN IT MANAGEMENT STRATEGIES FOR THE ENTERPRISE

Policies and procedures in IT Management are meant to ensure that critical systems stay current,
reliable, secure, and that they perform as needed. But, oh, it it were only that simple.........
Within the large corporate enterprise, the road to structured IT management is littered with
challenges and roadblocks. Management practices may take initial shape based on
technology requirements and established industry best practices. But, final form and
function are ultimately determined by organizational requirements, resource capabilities,
and internal politics.
IT Management Defined:
IT Management is defined by a set of practices, policies and procedures related to the
implementation, maintenance, and ongoing control of technology in business. Depending upon
the needs of the enterprise, IT management programs can be realized through a combination of
tools (hardware and software) and ideas (strategies, policies and procedures). These methods
and mechanisms will be determined in large part by technical requirements, organizational
issues, available funding and the degree to which technology management is embraced as a
strategic business function.
Based on these factors, an individualized IT Management program can include one or more of
the following elements, delivered in any number of ways:
Asset Management: to keep track of all hardware and software assets currently owned and in
use.
Change Management: to ensure that systems changes do not interfere with reliable operation
and availability.
Disaster Recovery & Contingency Planning: to protect the business in the event of a systems
outage, and/or loss of critical data.
End-User Support: to resolve technical problems and assist in the usage of technology.
Security Management: to protect business from data loss and systems damage due to hacking
and/or theft.
Software Licensing Control: to ensure compliance with licensing laws.
Systems Administration: to ensure that userids are current, access is appropriate, and that
storage capacity is kept at required levels.
Systems Management: to ensure that hardware and software configurations are current,
documented and performing as expected.
Technology Standards Management: to set product standards that ensure systems reliability,
compatibility and lower support costs.
Virus Protection: to protect desktops and servers from damage due to virus attacks.
IT Management Issues:
If IT management policies and procedures rested solely on technical requirements and best
practices, we might all do a better job of planning and implementing truly workable practices. But
things are rarely that simple ...
Organizational issues must also be factored into the development and implementation of IT
management practices ...
IT Structures: IT management practices must reflect the structure of the IT organization itself,
which can be organized in any number of ways. Traditional IT structures include centralization
(where all technology management functions are part of a single reporting structure),
decentralization (where technology responsibilities are distributed across multiple reporting
entities), outsourcing (where IT management responsibilities are handled by external service
providers), or hybrid (any combination of the three). These structures will determine systems
management responsibilities, while creating potential confusion and conflict in terms of ownership
and authority.
Internal Acceptance: How is your IT organization perceived by end-users and management?
Internal respect and acceptance of IT as a business partner can go a long way in determining the
extent to which systems management guidelines are accepted, particularly those that serve to
control systems access and utilization.
Management Support: Do you have sufficient management support for IT policies and
procedures? Since systems management procedures impact systems accessibility and
availability, sometimes restricting end-user functionality and independence, management support
is critical Without that support, there will be no supporting foundation for sensitive decisions that
may be in the best interests of the company, rather than the individual. If you lack this support,
you need to know why .... are IT policies inappropriate, are IT services inferior, does IT have a
bad reputation?
IT Management Risks:
The policies, processes and procedures involved in IT management are often referred to as "best
practices". But what works for one business does not necessarily work for all. If you implement
an ineffective or inappropriate IT management program you may run the risk that .....
Management costs will become too high.
Restrictive controls on the access and usage of systems will interfere will the productive
usage of those systems.
Your technical staff (if any) will not able to keep up with IT management guidelines.
You will not have the ability to enforce IT management guidelines.
You will implement policies, standards or procedures for the sake of control, not for the
needs of the business.
To avoid these risks, be sure to carefully evaluate not only your operational needs for IT
management, but also your internal capabilities for effectively supporting and executing an IT
management program.
CONCLUSIONS....
What will it take to plan and implement an effective IT Management program?

Step One: Assess Readiness - have you considered the degree to which reporting
relationships, IT reputation and management support must be factored into systems
management strategies?
Step Two: Identify Goals - what do you need to accomplish with an IT management program?
Step Three: Identify Technical Requirements - what IT management practices will you need
to put in place to meet operational goals and technical needs.
Step Four: Assess Internal Capabilities - do you have sufficient information, tools and
resources to implement your management program?
Step Five: Develop Management Program - devise and document your IT management
program and acquire any software/hardware tools that may be required to meet management
objectives.
Step Six: Test Management Program - test any automated processes and/or new operating
procedures to be put in place as part of your IT management program.
Step Seven: Communicate with End-Users & Management - provide training and information
all new IT management policies, processes and procedures.
Step Eight: Implement and Monitor - put your IT management program in place and
continually monitor progress and effectiveness.
Ideas into Action:
Use these quick tools to help you plan IT practices and services....
The IT Best Practices Evaluator
The IT Mission Statement Template
MORE ABOUT IT MANAGEMENT:
HOW TO IDENTIFY IT BUDGET PRIORITIES

IT budgeting is perhaps one of the most difficult tasks facing the IT manager, and odds are, no
manager faced with budget preparations, particularly in uncertain economic times, will be able to
please everyone. In all likelihood, IT staff will look at any proposed budget as a sign of IT
management strength, and the willingness to stick up for them and for "IT" organizational
interests. Company management will expect a realistic, probably "minimalist" budget, that
miraculously provides for the maximum services with the smallest possible price tag. End-users
may not even care about IT budgets, particularly if there are no charge-backs for IT costs, they
just want service and may not equate internal service limitations with actual budget limitations.
So what is an IT manager to do?
When preparing an IT budget, every IT manager must ensure that his/her budget is an
accurate reflection of business goals, technology needs and economic realities. When
presenting any budget for consideration, support and approval, the IT manager must also
be prepared to explain and justify that budget to ensure that all expense issues are clearly
defined, and realistic service expectations are set.
Here is a five step process to follow:
Step 1: Set Budget Goals & Strategies
Before you begin to prepare your IT budget, you should have a basic, and sound, understanding
of your overall budget goals. In all likelihood, these goals will have been set for you by your
management, and will depend in large part upon current business circumstances, economic
conditions, and the role that IT plays within your organization. As such, you should be aware of
your budgetary marching orders, which will likely encompass three realities:
You will be expected to maintain your prior budget ... you will get no less, but don't ask
for any more.
You will have to cut your prior budget .... which means you will have to do the same (or
more) with less.
You will be allowed to increase your prior budget in order to keep up with specific
business or technology needs.
Having to maintain or decrease your budget brings out another level of difficult decision
making......
Will it be possible to maintain the budget and still provide the necessary services and
projects?
If not, what items in the budget can be reduced to compensate?
If budget cuts are in order, how will essential services and projects be provided?
How will difficult budget decisions be made and communicated?
How will you deal with staff disappointments and end-user complaints?
Step 2: Identify Budget Factors
Depending on the size and structure of your IT operations, and the charter under which it
operates, and the services provided, any comprehensive IT budget will likely include the following
factors:
IT Staffing (Salaries, Benefits, Overtime)

Outsourcing (Consultants, Temporary Staff)
Travel (for Projects, Training and Multi-site Operations)
Infrastructure Asset Spending (Hardware, Software, Network and Telecommunications
Equipment)
IT Staff Equipment (Desktops, Test Equipment, Lab Equipment)
End-User Asset Spending (Depending on whether end-user desktop hardware and
software is part of IT spending or business budgets)
Services Spending (ASP's, Maintenance, Disaster Recovery)
End-User Training (Depending on whether end-user training is part of IT spending or
business budgets)
Internal IT Initiatives (Documentation, Policies & Procedures Development, Systems
Management Initiatives)
Step 3: Identify IT Priorities
Wishful thinking aside, IT priorities will rarely be the sole determining factor is the size and
application of the IT budget. But IT priorities are the starting point. These priorities can be
identified in three categories:
Technology Priorities: relating to the acquisition, upgrade and replacement of physical
technology assets, which can include hardware, software, and infrastructure equipment
(servers, networking, telecommunications, cabling and the physical premises needed to
house said equipment.)
Service Priorities: relating to the quality and quantity of IT services and the need to
improve, restructure, reduce or outsource. These services can include Help Desk, onsite technical support, training, systems performance management, and the delivery of
strategic planning services.
Project Priorities: relating to IT's ability to manage and support business initiatives
based on technology or requiring the support of technology. In short, IT's ability to deliver
projects requested by the business community.
Step 4: Identify Business Priorities:
In order to prepare a realistic IT budget, you must have a solid grasp on business priorities.
Based on the type of business, and current conditions and circumstances, likely business
priorities can include any or all of the following:
To cut costs.
To improve workplace productivity.
To deliver new or improved technologies.
To eliminate technology problems.
To improve IT services.
To improve systems performance.
Business priorities may not always be clear, and if you are not sure, ask. You can interview
managers, conduct surveys, or take advantage of staff observations made in the course of
projects and support activities. It will be difficult, if not impossible, to make difficult budget
choices, if you do not have a good understanding of the business needs and priorities.
Step 5: Align IT Priorities with Business Priorities:
The final step in this budget planning process is to align IT priorities with business priorities,
equating technology spending, IT services and projects with business goals.
As you begin this alignment process, you first need to look at your budget as a whole in terms of
overall goals and management directives....
Do you need to maintain, cut or increase the current budget from prior budget levels?
If you need to maintain the budget levels from your prior budget, will you need to
eliminate or defer any projects or planned initiatives that would require additional
spending?
If you need to cut (reduce) budget levels from your prior budget, how will those cuts be
made?....
Across the board (equally to all budget items)
Apportioned to specific budget items, leaving others intact.
Apportioned to specific budget items, allowing for necessary increases in some
areas, with corresponding cuts in others.
If you need to request budget increases, can those increases be justified on the basis of
IT and business priorities?
Once you are in the realm of tough choices, IT priorities and business priorities must be viewed
and properly aligned so that the informed choices can be made. If your investigation of business
priorities reveals that an improvement of IT services is essential, as opposed to an
implementation of newer technologies, your budget should reflect the funding needed to improve
IT services (i.e. increased staffing, salaries and/or training). You may not get all that you ask for,
but at least your request will be meaningful. And if your budget is not approved, you will have a
basis for further discussion if and when service complaints continue.
CONCLUSIONS:
Budget planning is an ongoing process, and first attempts may not always be approved. But,
when IT budgets are clearly equated with business goals, there is a greater chance of informed
decisions, realistic expectations and tangible results.
WORKBOOK PRODUCTS:
HOW TO MAKE TECHNOLOGY UPGRADE DECISIONS

Technology changes so rapidly that it sometimes seems as if we are all in a constant state of
conversion ... evaluating technology, testing, justifying, and installing .... only to begin again...
How can you tell if the time is right for yet another technology upgrade? ... this assessment tool
offers a roadmap for planning and analysis....
THE UPGRADE ASSESSMENT PROCESS:
Step #1: Classify the Upgrade
In order to properly make your upgrade decisions, you will need to assess the nature of the
upgrade, what it has to offer, and how it fits in with your current technical environment. To that
end, consider the following questions ...
What is the nature of the upgrade?... hardware, software, or infrastructure (cabling, network, or
telecommunications).
What does the upgrade have to offer?
updated functionality
new features
advanced use of technology
correction of bugs or other flaws
improved integration with other products
an opportunity to get the "latest and the greatest"
Step #2: Assess the Benefits
The next step in the assessment process is to evaluate likely benefits to be realized from the
upgrade.
Will the upgrade?....
correct serious problems that currently interfere with business or technical operations
improve systems performance
improve operational reliability
improve systems security
reduce support or maintenance costs
improve operations or ease of use
support key business requirements that the current version does not support
improve internal workflow productivity

replace older systems that are no longer supportable
help to meet regulatory or legal requirements
help to position the business for the future
Step #3: Assess the Value
There may be many benefits to any single upgrade, but in order to make your upgrade decisions,
you will now need to determine the value of any, and all, possible benefits to your business or
organization. After all, just because a benefits exists, that does not necessarily mean that it offers
sufficient value to warrant the expense and effort.
Value can be viewed from the following perspectives ....
Must Have: without this upgrade, there will be serious consequences ...
systems will fail
serious problems will continue
existing systems will no longer be supported by vendors
cost effective upgrade paths will be lost
expenses will climb or revenue will be lost
regulatory requirements cannot be met
Nice to Have: this upgrade would provide one or more benefits, but it is not
vital to continued technical or business operations.
Not Necessary: this upgrade offers us no tangible benefits at this time.
Step #4: Assess the Scope
If you have determined that an upgrade is not necessary as per Step #3 above, the scope
assessment process may not be warranted (unless you are curious, or need to further justify your
decision not to upgrade). However, if continued upgrade consideration is warranted, then you
can now begin to evaluate the effort involved in planning, installing and supporting the upgrade.
Compatibility Readiness...
Are you technically ready for this upgrade?
Technology upgrades are rarely one dimensional. The latest and greatest software upgrades
usually require more additional hardware power and capacity, and implementation can be much
more complicated than originally thought. As such, when planning an upgrade, several
compatibility issues should be considered ...
Can you run this software upgrade on existing hardware or will hardware upgrades be
required as well?
Will this upgrade (hardware or software) be compatible with other systems already in
place?
Do you have the internal expertise to install, maintain and support this upgrade?
Tasks ...
What activities will be required for planning and implementing this upgrade?
Project Management
Technical Design
Technical Testing
Contingency Planning (what if the upgrade fails?)
Installation
Training (IT Staff and End-Users)
Post Installation Support
Documentation Updates
Updates to Maintenance Procedures
Hardware Disposal Activities (if appropriate)
Resources...
What types of resources will be required to plan and install this upgrade?
Internal technical staff
External consultants or service providers
Temporary staff
Trainers
Timelines...
How long will it take to plan and install this upgrade?
Are there any time limits on installing this upgrade, or, if that time passes, certain tangible
benefits can be lost or lessened?
If you act quickly, can you take advantage of any special offers, promotions or discounts?
Should you wait out additional time for the upgrade to be fully tested out in the
marketplace?
Costs ....
What will the upgrade cost?
Purchase of required hardware and/or software
Compatibility upgrades (hardware or software)
Additional staff resources

Overtime Expenses
New office supplies (special paper, printer cartridges)
Additional cabling
Increased space for added hardware
Training classes
Hardware disposal costs
Step #5: Draw Conclusions
The analysis conducted in Steps #1 - #4 above should have prepared for the final decision ... to
upgrade or not to upgrade?
If have determined that this upgrade is Not Necessary, then no further action is
probably necessary.
If you have determined that the upgrade is a Nice to Have, then you need to look
carefully at your scope issues identified in order to weigh costs and efforts against
benefits. At this point, you may also need also consider any viable alternatives, as well
as the risks involved in taking no action for now.
If you have determined that the upgrade is a Must Have, then you will probably need to
proceed with your planning and implementation efforts. If the costs of this upgrade are
too high, then you may need to begin a thorough consideration of any and all
alternatives - perhaps you can implement a partial upgrade, or look to other, less costly
product alternatives.
MORE ABOUT TECHNOLOGY UPGRADES....
The Technology Upgrade Planning Template
Apply the upgrade analysis principles documented here with this easy to use planning
worksheet.....
Specify upgrade characteristics, evaluating and prioritizing upgrade goals, savings and
benefits.
Estimate upgrade costs and related savings, considering equipment costs, maintenance
costs, installation costs, and other cost factors.
Assess the scope of the upgrade work effort, considering technical compatibility, work
hours required, scheduling requirements and other implementation factors.
Make and document informed upgrade decisions, based on an informed analysis of
overall upgrade value.
HOW TO PLAN AN IT OPERATIONS AUDIT

The mere mention of an "audit" is enough to make anyone nervous. But, put in proper
perspective, an audit of IT operational policies and procedures is an effective means of assessing
the viability of IT services and functions.
An audit will serve its intended purpose if two primary objectives are reached:
Audit goals are clearly defined in advance, stating the purpose of the audit and the
expected results.
Audit results are applied to improve the quality and integrity of technology
operations, and related services.
Step One: Set Goals and Objectives
The first step in planning an IT audit is to create a clear statement of goals and objectives,
defining the purpose of the audit, expected benefits and desired results.
When preparing your audit statement, the following questions should be addressed:
Who is conducting the audit?
Within larger corporate environments, IT audits may be conducted by a separate audit
department, or in other cases, IT may use a formal audit process as a means of self-evaluation.
Why is the audit being conducted?
In the event that IT policies and procedures are well established, IT audits will most likely serve
a validation function, to ensure operational compliance. However, in the event that IT policies and
procedures are not well-defined, audits can serve an analytical purpose, to assess IT operations.
Furthermore, an audit can be a helpful investigative tool applied after a major systems failure, to
uncover problems and develop operational remedies.
What is the audit scope?
A specification of scope will determine the subject of the audit process, typically stating the
systems and procedures to be reviewed. Audits can include any or all IT systems and services,
including physical equipment, systems management procedures, outsourced functions and
support services.
What are the audit goals and objectives?
The specification of audit goals and objectives should define the purpose and benefit of the audit.
As discussed, audits may be designed to measure compliance, to find variances, and to look for
improvements. Audits should not be used to assign blame or as the sole measure of IT
"performance". Audits are tools, and should be used to gather and report information.
Step Two: Define Audit Specifics
Audit specifics will further refine your audit scope, defining the exact "subjects" of the audit
process. Audit specifics will vary based on the structure and charter of your IT organization, the
systems in place, available time, and your audit goals and capabilities. In most cases, a
comprehensive IT audit will include a review of the following:
Physical Security: to ensure that appropriate physical controls are in place to secure
technology assets (servers, networking and telecommunications equipment) preventing
unauthorized access.
Logical Security: to ensure that appropriate software security controls are in place to
prevent viruses and unauthorized data access.
Logistical and Environmental Controls: to ensure that systems, networking and

telecommunications equipment are housed in facilities designed to offer proper
environmental conditions (regarding temperature and dust regulation, furniture, racks and
physical equipment organization).
Configuration Management: to ensure that systems are installed and configured
according to established requirements and standards.
Systems Administration Procedures: to ensure that security and systems
administrative procedures are properly defined and assigned to staff.
Hardware Inventory Management: to ensure that all hardware is properly inventoried
and that warranty and maintenance records are maintained.
Software Licensing Compliance: to ensure that all software usage is in compliance with
licensing agreements, and that appropriate licensing records are maintained.
Data Backup and Disaster Recovery Procedures: to ensure that data backups are
being made and tested on a scheduled basis, sufficient to recover in the event of a
systems failure, data loss, or other disaster.
Documentation: to ensure that all systems, procedures, and policies are properly
documented and updated, including the appropriate retention of systems reports, error,
help desk, and other related problem logs.
Performance and Capacity Planning: to ensure that all systems are performing
according to required levels, considering uptime, systems availability, bandwidth, data
storage availability, and the archival of older data files.
Change Management: to ensure that all major changes to systems hardware and
software are properly documented, tested and verified prior to implementation, with
appropriate back-out plans.
Step Three: Define the Audit Process
Once you have defined your audit goals and objectives, you will need to specify the audit process
i.e. how your audit will be conducted. You will need to create your audit team, and assign roles
and responsibilities. Exact audit procedures will vary based upon the systems being audited, and
the size and scope of the audit itself. In most cases, IT audit procedures can include any or all of
the following:
Hands-on, on-site, technical reviews (using automated tools or manual procedures).
Procedures testing and validation.
On site premises inspections
Interviews with IT staff.
Physical reviews of technical documentation, logs and systems reports.

Interviews with end-users.
Step Four: Conduct the Audit
Audits should not be surprise attacks ... they should be scheduled events. It is very difficult fake
IT compliance, and very little can be gained from unscheduled audits. If a pending audit causes
IT staff to clean up minor errors and omissions, then the goal of the audit has been largely
reached ... to ensure compliance. For an audit to be truly effective, communication and
cooperation is essential, and that can only be obtained through a non-threatening process of
review and evaluation.
Schedule the audit with IT managers and any essential staff.
Request any special security requirements in advance (ids, passwords).
Identify any required documentation, logs and records.
Schedule time for an informal review of preliminary results.
Step Five: Applying Audit Results
Before you begin your audit, you should set clear expectations for the use and application of audit
results. Since "blame" should not be the goal of any audit, audit results should be clearly and
openly communicated. While all results may not be positive, at the end of the process, there
should be a clear direction for improvement.
CONCLUSIONS.....
If audit results show a lack of compliance, the reasons must be evaluated . perhaps IT has not
been properly funded, or policies are unrealistic and inappropriate, and compliance is impossible.
Audit results have to be viewed as a whole, in context of IT funding and staffing capabilities, and
potentially reasonable IT practices. And overall, auditing is a means to an end, not a goal in and
of itself. The ultimate goal is to ensure that essential systems are reliable and secure, and that
technology is used to support and advance key business needs and objectives.
DOWNTIME: IT WILL COST YOU

Downtime cost analysis is a numbers game. The objective is simple to find the magic
number.the point at which the costs of downtime exceed the costs of prevention and
mitigation. This is the point of justification....
Playing the Game
Everyone knows that downtime is costly. Everyone also knows that downtime is preventable (to a
certain extent), and certainly, what cannot be prevented, can be managed and mitigated. But this
knowledge alone may not move anyone to act, largely because "action" is also costly. It takes
time, money and staff resources to analyze needs and develop working solutions. And, above all,
expenses have to be justified.
To play the game, IT staffers must be able to quantify the costs of downtime in real business
terms .... moving downtime from the realm of complaint into "costs and consequences". To
achieve this goal, the following questions must be addressed:
What is downtime?
"Downtime" is hard to define. The meaning will vary by organization, person, system and event.
On a big picture level, downtime occurs whenever a given system (application, server, network)
cannot be accessed or used for its intended purpose. Obviously, there are "shades" of downtime
based on the degree of impact (intermittent interruptions or full-blown outage), duration,
frequency, visibility (internal systems versus external systems for customer usage), and extent
(the number of end-users and locations involved). These "shades" drive related costs and the
need for effective management solutions.
What is downtime management?
Downtime management is a combination of physical solutions (hardware and software) and
logical practices (policies and procedures). The goal of downtime management is prevention (to
minimize downtime occurrences) and mitigation (to minimize the impact of downtime when it
occurs).
What are the costs of downtime?
Downtime costs must be viewed in terms of "tangibles" and "intangibles".
Calculating Tangible Costs:
Step 1: Identify the systems to be reviewed, including any infrastructure devices, servers,
desktops, applications and productivity systems (phone, email, video-conferencing, internet
access). To complete your analysis, you must understand how a given system is used, and its
value within the organization in terms of:
Revenue: Is the system directly involved in revenue generation, i.e. ecommerce?
Operations: What internal operations does this system support?
Productivity: How is this system used to increase internal productivity?
Customer Relationships: What role does this system play in the service of external
customers?
Regulatory Requirements: How does this system help us to meet regulatory
requirements?
Step 2: Identify a typical downtime scenario to use as a costing example.
Step 3: Identify your cost factors:
Cost Factor
You need to know:

A= Number of Users Involved
End-User Costs:
B = Hourly Cost per user

C = Number of Hours Lost
A x B x C = End User Cost
End-User Overtime Costs
The amount of money paid in overtime to employees directly

resulting from downtime.
A = Number of IT Staff involved in Downtime Resolution.

B = Hourly Work Cost per IT Staffer
IT Staffing Costs
C = Hours Spent in Downtime Resolution
IT Costs = A x B x C
IT Overtime Costs
The amount of money paid in overtime to IT staffers as a direct

result of downtime.
Vendor Costs
Monies paid to vendors or consultants to resolve downtime.
Recovery Costs
Monies spent to restore data lost as a result of downtime.

Revenue lost as a direct result of downtime:
Lost transactions.
Lost Revenue
Lost contracts.
Lost customers.
Emergency Processing
Costs
The costs of alternative processing activities (the cost to

complete work that could not be completed due to downtime.)
Example: Outsourcing printing operations because internal
printers are unavailable.
Regulatory Costs
Monies paid in fees and fines as a direct result of downtime.
Calculating Intangible Costs:

Downtime costs extend beyond dollars and cents, into the intangible realm of workplace
productivity. Considering the sensitivities involved, downtime can become quite personal ("I cant
get my work done because of you and your systems", or "My customer is mad at me because of
you and your systems"). As such, downtime can have a negative impact on:
IT/End-User Relationships
Organizational Trust in Technology (leading to a technology aversion and an
unwarranted reliance on manual operations).
Staff Morale
Company Reputation
External Customer Relationships

Future Growth and Revenue Potential
What are the costs of downtime management?
Downtime can be prevented (to a certain extent) and it can be managed, but at a price. To
identify the costs associated with downtime management, you first have to examine the
alternatives for prevention and mitigation:
Hardware Solutions: Physical hardware solutions needed to prevent or mitigate
downtime occurrences.
Software Solutions: Physical software solutions needed to prevent or mitigate
downtime occurrences.
Systems Management Practices: Procedures and practices used to manage systems in
order to prevent or minimize downtime impact.
Administrative Practices: Procedures and practices used to manage userids,
passwords and technical support as part of the effort to prevent or minimize downtime
impact.
Each of these solutions and practices have to be planned, implemented and maintained. As
such, there are costs.....
Tangible Costs:
Design and Development: Costs to analyze, design and develop technical solutions and
management procedures.
Acquisition: Purchase costs for hardware and software solutions.
Implementation: Costs to implement solutions and practices (including internal and
external resource costs).
Training: Costs to train IT staff and end-users.
Management Overhead: Costs to maintain downtime management solutions and
practices on an ongoing basis.
Intangible Costs:
Systems Overhead: Loss of performance due to downtime prevention measures
(redundancies, security, virus protection, etc.)
Usability Impact: Cost to personal "end-user" productivity as a result of downtime
prevention measures.
Put it all together.
Once you can identify the costs of downtime, contrasted with the costs of downtime management,
you will be in a position to weigh overall costs and benefits. The primary working assumption has
to be this:
Downtime is costly and unproductive and should be avoided to the extent possible and practical.
The question is . what is "possible and practical"?
The answer will vary by organization, circumstance, and even by individual system. To find your
"possible and practical" solutions you will need to weigh individual downtime consequences
against viable management solutions, looking to find the right balance between cost and benefit.
Obviously, IT must take advantage of all available "best practices" to ensure that technology is
properly installed and maintained. But, fully redundant hardware systems, while theoretically
desirable, may not be cost justified under all situations.
CONCLUSIONS.....
Any steps taken to prevent and mitigate downtime must be targeted (relevant to business needs
and downtime costs), realistic (you must have the staff and the resources to make it happen),
and effective (it has to get the job done). As costly as downtime may be, the costs of false
expectations and unfulfilled promises may go beyond actual measurement.
NEW VERSION NOW AVAILABLE! In Download or Print/CD Editions...
The Disaster Recovery Plan Process Kit (Version 3) gives you the tools and resources you
need to take you from "A to Z" in disaster recovery planning. You will analyze needs, select
strategies, organize resources, write your plans and ensure plan relevancy through ongoing
testing and lessons learned analysis.
(115+) pages filled with how-to guidelines and insights to lead you through the
disaster recovery planning process, from needs analysis to DRP testing.
Quick reference Glossaries and "Planning Snapshots" to help you save time and get
a head start on the planning process.
Easy to follow project planning steps and instructions to help you plan, schedule and
monitor "disaster recovery" tasks and activities.
(3) Interactive planning forms (in PDF format) to assess disaster readiness, define
business impact, track disaster recovery planning activities, and audit DRP performance.
And, with the new data export function, you can quickly extract form data to external
applications for your own customization.
A customizable, (40) slide "project" presentation template (in PowerPoint format) to
help you kick off, manage and justify your "Disaster Recovery Plan Project".
(3) Pre-formatted templates (in Word format) to help you draft, finalize and approve
essential disaster recovery documents, including the Disaster Recovery Plan and Test
Plan. Each template includes content guidelines and auto formatting features to
streamline document production.
HOW TO PLAN DATA SECURITY POLICIES

Effective data security planning will be the result of a solid partnership between IT and the enduser community. Each "partner" in this important process plays a specific and valuable role:
The end-user defines the need (the data to be protected and the business basis behind
the security requirements).
IT provides the technical means by which the identified data security needs can be met.
Considering the complex nature of most technical environments, and the naturally restrictive
intent of most data security policies, success is unlikely without sufficient collaboration and
cooperation. To increase your odds, the following goals should apply....
Data security needs must be clearly defined according to data type and user type.
Data security policies must be designed to match needs and technical capabilities.
End-user cooperation is essential for success (i.e. a shared password is most often a
useless password).
Data security policies must be consistently enforced in order to maintain credibility.
Management support is essential.
As technology changes occur, data security policies must be continually updated and
maintained.
What is data security?
Data security relates to the protection of specific data repositories, which can include databases,
applications, directories and specific data files. Depending upon individual needs, "protection"
can serve several purposes....
To secure data from unauthorized access.
To limit applications access to licensed employees.
To minimize accidental data loss.
To prevent malicious data loss.
To demonstrate compliance with industry standards, contractual obligations and/or
governmental regulations.
Considering the varied objectives and related benefits, data security policies should address the
following issues:
Data Guidelines: To identify the applications and data covered by the policy. These
guidelines should address security needs for specific data files, applications, directories,
intranets, email and any other related systems.
Access Rights: To identify data access rights according to staffing requirements and job
functionality. Data access rights determine who can view, enter, modify, update or delete
data.
User Guidelines: To identify access by type of user. Depending on individual needs,
user types can include full-time staff, part-time staff, contractors, departments,
management, executives, customers, special project groups, and the public.
Security Architectures: The combination of hardware devices and software parameters
used to implement data security policies.
Password Standards: To establish standards for passwords, including minimum length,
maximum length, character types, change requirements, single sign-on capabilities and
new user set-ups.
Roles and Responsibilities: To identify the various roles and responsibilities for IT staff,
end-users, business managers, and data security planners.
Information Classifications: To quantify protected data according to standardized
information categories, setting the standard for policy application. (Examples:
Confidential, Proprietary, Internal, Public). These classifications can then be applied
according to data type, facilitating policy administration.
Administrative Procedures: To identify the procedures required to implement, maintain
and update the data security policies.
Exceptions and Waivers: To establish the procedures by which data security policies
can and should be waived, including a specification of the procedures by which waivers
can be requested.
Audit and Review: To identify audit guidelines and procedures. Data security audits
should be conducted on a periodic basis to ensure that data policies are enforced and
followed. Audits should also be used to ensure that data policies are effective, relevant
and have kept pace with technology changes.
The complexity and formality of any internal data security policy will vary according to
organizational size, technology needs, internal management capabilities and security
requirements. Details aside, any effective data security policy will be the result of structured
process designed to promote collaboration and cooperation, with a focus on practical needs and
technical capabilities.
The following section lays out an eight step process for policy planning and development:
Step 1: Select your policy team.
Depending on your needs, your data security team should include representation from both the
technology and business arenas. You might also need input from Legal, Human Resource or
Audit departments.
Step 2: Identify your goals.
What are you trying to accomplish? Based on timing and circumstances, data policy projects
may be undertaken for any number of reasons:
To create a new policy where none exists.
To respond to a specific security breach.
To revise an existing policy in response to business or technology changes.
Step 3: Identify data security requirements.
To identify your data security requirements, consider the following questions:
What types of data will be covered by this policy?
What level of protection is required for each type of data?
How will data access rights be identified and allocated?
How will systems functionality and workplace productivity be impacted by data security
restrictions?
How will data security restrictions impact business continuity requirements?
Step 4: Identify technical capabilities.
Technical capabilities must be evaluated to determine current security capabilities. You will need
to account for the following:
Architecture: the configuration of hardware devices and software parameters.
Identification capabilities: how do your systems identify users?
Authorization capabilities: how is data access granted?
Authentication capabilities: how is user identity and access verified?
Problem management capabilities: how will access problems be tracked and solved?
Reporting capabilities - how can access be tracked to identify security breaches and
related problems?
Step 5: Identify alternative solutions:
Using identified data security needs, contrasted with technical capabilities, identify alternative
solutions and approaches to data security management. These solutions and approaches may
include hardware solutions, software solutions (auditing tools, single sign-on), security
configurations, password set-ups, user profile management, as well as related policies and
procedures.
Step 6: Analyze alternatives:
At this stage, data security alternatives should be analyzed and evaluated to identify the best
solution. Evaluation criteria can include:
Implementation work effort.
Required skills.
Estimated costs.
Administrative overhead.
Expected benefits.
Step 7: Select the appropriate alternative.
Document data security recommendations based on the aforementioned analysis. This
documentation should describe the overall solution, providing business justifications and the
related cost benefit analysis. In addition, any data security needs that cannot be met should be
clearly delineated.
Step 8: Obtain the necessary approvals.
Be sure to obtain consensus and acceptance of the planned data security policy before any steps
are taken for implementation.
THE BASICS OF IT DISASTER RECOVERY PLANNING

Disaster recovery planning is the mechanism by which technology disasters are anticipated and
addressed. The first challenge in this planning process is to quantify the meaning of the word
"disaster" in the IT environment. In IT, a disaster can be any unexpected problem that results in a
slowdown, interruption or failure in a system or network. These problems can be caused by
natural disasters (i.e. fire, earthquake, hurricane), technical failures, malicious acts,
incompatibilities, or simple human error.
Whatever the cause, service outages, connectivity failures, data loss, and related technical issues
can disrupt business operations, causing lost revenues, increased expenses, customer service
problems, and lowered workplace productivity.
IT disaster recovery planning strategies must be created to respond to these varied realities and
perceptions. To that end, these strategies must address three basic needs.
Prevention (to avoid and minimize disaster frequency and occurrence)
Anticipation (to identify likely disasters and related consequences)
Mitigation (to take steps for managing disasters to minimize negative impact)
THE BASICS OF IT DISASTER RECOVERY PLANNING
Prevention
The goal of "preventative" disaster recovery planning is to ensure that all key systems are as
secure and reliable as possible, in order to reduce the frequency or likelihood of "technology
related disasters". Since natural disasters usually lie outside our sphere of influence, prevention
most often applies to systems problems and human errors, to include physical hardware failures,
software bugs, configuration errors and omissions, and acts of malicious intent (virus attacks,
security violations, data corruption). Using the right set of tools and techniques, it is possible to
preclude both the occurrence and related damage from any and all of these sorts of "disasters".
WHAT CAN YOU DO TO PREVENT TECHNOLOGY DISASTERS?
Configure systems according to tested standards and manufacturer recommendations.
Apply software patches and bug fixes on a regular basis.

Monitor systems on a regular basis to ensure proper performance and storage capacity.
Use virus prevention and detection tools.
Use a backup power supply and surge protectors to prevent damage and data loss from
electrical spikes and power outages.
Configure critical systems with equipment and storage redundancies.
Use software tools and appropriate management techniques to prevent security
violations.
Set hardware and software standards to minimize the range of potential problems, and to
facilitate problem resolution..
Anticipation
Anticipation strategies revolve around "assumptions" . the ability to foresee possible disasters,
in order to identify possible consequences and appropriate responses. Without a crystal ball,
contingency planning can be a challenging process. It involves knowledge and careful analysis.
Knowledge is derived from experience and information . understanding the systems you have,
how they are configured, and what sort of problems or failures are likely to occur. And the related
analysis involves a careful balancing of circumstances and consequences.
ANTICIPATION TECHNIQUES PLAYING THE "WHAT IF" ANALYSIS :
Step 1: Identify potential disaster scenarios (what can happen?)
Step 2: Quantify probabilities (what is the likelihood that a given disaster will occur?)
Step 3: Articulate consequences (should this disaster occur, what would the impact be
upon our business and our staff?)
Mitigation
Mitigation is all about "reaction and recovery" . the ability to respond when and if a disaster
occurs. Accepting that certain disasters are unavoidable, and perhaps inevitable, the goal of any
mitigation strategy is to minimize negative impact. Depending on your available resources, and
particular technical environment, there are many tools and strategies available for an effective
mitigation program.
WHAT CAN YOU DO TO MINIMIZE DISASTER CONSEQUENCES & IMPACT?
Maintain current technical documentation to facilitate recovery should a problem occur.
Conduct regular tests of your disaster recover plans and strategies.
Keep loaner equipment available for immediate use.
Make regularly scheduled backups and store them in a safe off-site location.
Maintain a remote access plan to allow designated staff to work from home or other
location.
Identify manual or standalone operating procedures in the event of a prolonged outage.
Coordinate IT disaster recovery and business resumptions plans with basic emergency
and employee safety programs.
THE BENEFITS OF DISASTER RECOVERY PLANNING
Effective disaster recovery planning and consequence management can offer many benefits to a
business. Once you acknowledge the value of technology to your organization, you must also
consider the related consequences when and if that technology becomes temporarily unavailable,
or totally inaccessible. Your ability and willingness to address these issues can offer several key
operational benefits:
Why implement disaster recovery management?
To minimize the negative impact of any disaster.
To save time and money in the recovery process in the event of a disaster.
To provide for an orderly recovery process, reducing "panic" decision making in the midst
of a disaster or problem.
To lower insurance premiums.
To protect technology assets owned by a business, maximizing ROI.
To minimize legal or regulatory liabilities.
To promote systems and IT service quality, reliability and security.
To promote the value of technology and related IT services within your organization.
To promote management awareness, and to set realistic expectations about the need for
systems management tools and resources.
These benefits form an impressive list, but as with any other management practice, these
benefits come at price. Effective disaster recovery planning costs time and money in terms of
effort, skills, staff resources, and implementation tools (i.e. hardware and software).
As such, the benefits must be weighed against the costs to determine the overall business value.
You may want to prepare for each and every disaster, but financial realities and resource
capabilities may preclude that level of protection. It all comes down to a careful balancing
between business needs and practical realities.
HOW TO PLAN BACKUP POLICIES & PROCEDURES

Backups can be your ultimate systems safety net......with a good backup you can recover from
any accidental (or not so accidental) data loss, virus incident, or critical hardware failure.
And while all backups are "created", good backups are also managed, maintained and
secured .... a difference realized through reasonable management practices. Whether you
choose to backup to tape, disk, CD, or other medium, without effective backup practices,
you will not be able to guarantee that your safety net will be available when it may be most
needed.
It may take some time and effort to develop the best backup practices, but the following checklist
can get you going in the right direction. As you go through this evaluation process, keep an eye
on the goal .... to develop a viable plan for backup and recovery, taking the needs of your
business, and the realities of limited resources into consideration.
Determine what you will backup - data, applications or both.
Your first step is to identify and quantify the data for backup. This will help you determine an
appropriate backup schedule and will also define your storage requirements. For example, you
may not have the storage capacity to backup all data and applications on a daily basis. As a
result, you may need to define exclusions and exceptions, and then let everyone know what will
be backed up, and when.
What should be backed up?
Business Data
Memos, documents, customer information, financial records, databases, accounting
information, project data, schedules and appointments, e-mail, and any other critical files
Systems Data
Software and hardware configuration data, software applications, user ids, access rights,
directory structures, passwords, e-mail configurations, and any other specialized systems
information
Define your goal - What are you trying to achieve with your backups? Quick data recovery, data
archives, disaster recovery, or month-end and year-end closures? There are many operational
reasons for backups, but each one may require a different preparation or maintenance process.
Why do I need to backup?
To protect my business from data loss due to systems failure, virus, vandalism,
operator error, or accidental erasure.
To meet regulatory requirements.
To free storage space.
To archive older files.
To prepare for a systems upgrade, conversion, or replacement.
Balance recovery needs with costs.
Backups require time and effort for proper maintenance and administration. To strike the right
balance between cost and benefit, consider the intended use (i.e. off-line storage, data recovery,
etc.), weighed against the costs of creation, storage and maintenance. In addition, you will also
need to consider your available staff resources, and the time it will take for one or more
individuals to properly manage the backup process.
Consider the medium.
What medium will you use for backups (i.e. tape, disk to disk, CD)? Medium should be examined
for capacity, cost, performance, and shelf life (i.e. how long can it be stored and how often can it
be re-used?)
Assign and document responsibilities and accountability.
Make sure that all staff are aware of backup policies, procedures and schedules. Even if not
directly responsible for the creation of backups, anyone creating data has a stake in backing it
up. Your staff should have access to information concerning file storage and related backup
policies and schedules.
Set an effective backup schedule.
Be sure that your backup schedule is in compliance with technical needs, and your completed
cost/benefit analysis... whether that schedule calls for daily, weekly, monthly backups, or a
combination of the three.
How often do I need to backup?
Daily - for data that changes on a daily basis
Per an established schedule - for data that changes at scheduled intervals, or to respond
to a major systems event
At month and year end - for systems with closing dates.
Label all backup medium.
Backup labels should include both physical and systems labels. It is best to use a simple, but
meaningful system so that you can easily locate data for retrieval.
Store backups in a secure location.
At a minimum, backups should be stored in fire proof cabinet, as they will do you little good if they
are lost in an office fire, along with all your desktops and servers. You may also want to consider
your needs for off-site storage. While offering additional protection and security, there will also
be additional costs and retrieval complications.
Never assume.
Backup systems can experience failures just like any other system....so be sure to test and verify
your backups often, and make multiple copies as needed. As an example, if you are moving your
office, you may want to make multiple copies of your backups - one to store and one to take with
you. In this way you will be prepared for any eventuality, such as a loss of data from physical
damage to equipment during the move.
TOO OUTDATED TO UPDATE? USING "THE LEGACY SYSTEMS

ANALYSIS"
What is a legacy system?
A legacy system can be simply defined as a "prior generation" computer system which is
technically incompatible with other "current generation" systems, but still provides operational
value to one or more end-users. Legacy systems are not strictly defined by size, platform or
function. Typically, legacy systems reside on mainframe or mini-computers, but they may also
exist in that old PC sitting in the corner running that homegrown inventory database that no one
can live without.
Legacy systems present obvious problems for the IT service and support operation. Maintenance
and technical support can be difficult, particularly as time passes, and the pool of skilled support
and repair resources shrinks. In fact, support costs alone may justify replacing a legacy system.
But, legacy systems are more than just hardware and software they are are also operational
"legacies", having formed attachments at a job security and productivity level. This operational
bond can be personal and emotional, manifested by an outward resistance to change. As a
result, any process used to assess and analyze legacy system viability must account for all the
technical issues, business variables, and emotional elements involved.
The Analysis Process .
Step 1: Identify Goals and Objectives
Before your analysis begins, you must have a clear understanding of specific goals and
objectives. In all likelihood, the primary goal will be to evaluate legacy systems viability in order to
determine whether the system should be retained, replaced or eliminated.
Step 2: Identify Process Stakeholders
Once goals and objectives have been defined, process "stakeholders" must be identified.
Process stakeholders should be chosen according to "impact and input"..
Who will be impacted by the retention, replacement or elimination of this legacy system?
Who can provide input into the analytical process?
In all likelihood, your process stakeholders will include:
Technical representation (from IT and/or current systems service providers).
End-user representation.
Management representation.
Step 3: Evaluate Systems Viability
This systems viability analysis must be designed to consider all the necessary elements for
analysis, including business value, technical considerations and emotional impact.
Questions to Consider..
Business Viability Questions:
What operational function does this legacy system serve?
What value does this system provide to the organization? (financial and/or operational)?
Technical Viability Questions:
How is this system currently supported and maintained?
What are the current costs of systems support and maintenance?
What are the current or expected limits to support and maintenance (i.e. expected limits
to replacement part availability)?
Are any other systems connected to, or dependent upon, this system in any way?
What are the technical risks (i.e. an inability to recover from a disaster, lack of
documentation, security issues, etc.)?
Emotional Impact:
What business units and end-users are currently involved in the use of this system?
How long has this system been in use? (i.e. to assess the degree of attachment).
Do your end-users see this system as a "problem" or does it just run? (i.e. Will you be
taking away a system that "works" and replacing it with an unknown?).
Will any workers lose their jobs or face re-training if this system is replaced or eliminated?
Will you face any resistance to change and how can that resistance be addressed?
Step 4: Evaluate Alternatives
Having assessed the viability of the system under review, you can now consider the alternatives
for action. These alternatives will likely fall into three categories:
Retention: To keep the existing system as is.
Replacement: To migrate the system and move its functions to another platform.
Elimination: To remove the system and provide no replacement.
Each of these primary alternatives can be evaluated according to the following factors:
Impact: How will retention, replacement or elimination impact the business?
Costs: What are the costs involved in retention, replacement and elimination?
Degree of Difficulty: What steps are involved in retention, replacement and elimination,
and do you have the time, skills and required resources required to deliver each
alternative? If not, which alternatives can be met?
Risks: What are the risks involved in retention, replacement and elimination?
Benefits: What are the benefits involved in retention, replacement and elimination? (i.e.
increased productivity, lowered support costs, increased security, etc.)
Service Quality: How will retention, replacement or elimination impact current IT service
level objectives and agreements?
Step 5: Recommend Solutions
Once your alternatives have been examined, conclusions must be reached and decisions must
be made. These recommendations will result from the balancing of legacy systems viability and
alternatives potential. For example, if you have a legacy system that provides high business
value, but presents minimal support and cost issues (i.e. the thing just runs), it may make sense
to leave it alone despite the fact that the underlying "technology" may be outdated. On the other
hand, a system that presents high business value, and equally high retention risk, that system
may be well suited for replacement no matter how costly or difficult that replacement may be.
Specifics aside, any final legacy system recommendation must be clearly defined and
documented, providing justifications and reasoning for any conclusions reached.

ITProject Management

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ITProject Management

Hochgeladen von

Copyright:

Verfügbare Formate

PROJECT MANAGEMENT SKILLS & CERTIFICATION OPTIONS

Unique outcomes (deliverables).

Specific start and end dates.

Scheduled path (tasks, events and activities)

Assigned resources (people, equipment, budgets).

Risks, constraints and assumptions.

What is project management?

The degree of familiarity with project management theories and

The ability to execute project management responsibilities to

issues tracking and progress measurement. Soft Skills: leadership,

The ability to use available project management tools (software) to

The ability to apply knowledge, skills and tools in appropriate

The Project Management

Initial certification valid for

Available since 2001

Related Quick Tools:

The implementation of new technology....

Upgrade or migration of existing technology....

Change in policy or procedure....

___ Increased revenue opportunities

___ Maintains or improves systems security

The Problem Management Policy Kit

HOW TO MANAGE THE PROJECT SELECTION PROCESS

Resources are "used up" before projects can be completed.

Resources are wasted in projects of lesser value and priority.

Level 1: Individual Viability. The degree to which a proposed project is viable as an

Goals & Objectives

Roles & Responsibilities

Process Component #1: Organization

To evaluate proposed projects according to a set of pre-defined criteria.

To weigh proposed projects and make appropriate selections based on

To engage in a collaborative process with all process stakeholders to ensure

To review, approve and/or reject project proposals in a timely manner.

To communicate status, issues, conclusions and justifications in an open and

Process Component #3: Deliverables

Project Proposal: To provide basic project information, and activate the

Business Case: To provide the business justification needed to support

Project Review Scorecard: To evaluate the proposal according to pre-defined

Selection/Rejection Notification: To document and communicate the results

Process Component #4: Roles & Responsibilities

Management - to lead the process as project proposals are received, reviewed

Participation - to complete assigned tasks for proposal submission, review,

Support - to promote the process within the organization.

Process Component #5: Steps

Criteria: The specific characteristics for viability measurement.

Weight: The comparative ranking of multiple project proposals.

Sets useful standards to guide decisions.

Saves time and minimizes redundancies.

Minimizes knee-jerk responses to project requests.

Promotes cooperation and collaboration.

Provides a "big picture" perspective, providing context for proposal review.

BREAK IT DOWN: HOW TO CREATE PROJECT DEFINITIONS

Explicit and unambiguous: to clearly state requirements and establish common

Measurable: so that results can be quantified....

Time specific: establishing deadlines for completion and progress measurement....

Controllable: so that progress can be monitored and changes controlled....

2. Phases, Tasks and Activities:

How long have similar tasks taken in the past?

How have similar projects been organized and scheduled?

What resources were required for completion?

What improvements can be made based on past experiences?

Project Scheduling Strategies

Communication: to ensure effective utilization of meetings, status reporting, and

Change control: to facilitate change requests and avoid creeping scope....