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

Overview

The Computing Technology Industry Association (CompTIA) provides certification in multiple subject 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).

Requirements Single Exam

Combined requirements of formal education, experience, training and exams.

Longevity Lifetime Certification

Initial certification valid for three years, with continuing requirements to maintain.

Structure

Certification relies on (4) subject areas: (1) Project Initiation & Scope Definition, (2) Project Planning, (3) Project Execution, Control, & Coordination, and (4) Project Closure, Acceptance & Support

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.

Acceptance

Available since 2001 (acquired from Gartner).

Available since 1984.

Testing & Application Costs

Varies by membership status (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:

Project Initiation.... The Project Planning Roadmap




Proactive Problem Management........ The Problem Management Policy Kit


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

Quality Specifications

To name the tasks, tools and resources needed to identify quality requirements and expectations. 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 "in-house 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 decision-making 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 To what degree does this proposal meet stated service requirements?

Pricing How does the proposed price compare to the (a) planned budget and to (b) other proposals?

Delivery & Installation To what degree does this proposal meet 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 Statement of Work Process Kit

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

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.

Consulting Project manage

Date post:	05-Nov-2015
Category:	Documents
Upload:	adedire-fisayo
View:	266 times
Download:	0 times