Human Resource Management

In this post we will clarify the high level roles and responsibilities of the project stakeholders.  Please note that it would easily be possible to write a whole book on this topic. A good starting point for more detailed information is here

Project Sponsor

• accepts the product of the project
• might set milestones, deliverables and due dates

Senior Management (anyone above the project manager)

• determines priorities (conflict of scope, cost and time)
• protects the project

Project Manager

• must have the necessary authority to accomplish the work
• leads and directs the project planning work
• is responsible for the project but not necessarily for the project resources

Project Team

• Identifies assumptions, constraints, dependencies and risks
• creates the work breakdown structure including cost + effort estimates

The Responsiblities in a project should be captured in a RACI chart. This requires considerable work upfront but will payoff with less confusion later in the project.
According to PMI the Project Manager has different powers that he/she can use to get the project team to perform. The options that will help the most are

1. Expert knowledge of the Project Manager
2. Strong support of the project manager and/or project by management

The level of authority for the Project Manager may vary depending on the form of organization ( and determines which conflict resolution techniques the Project Manager can use.
In general it is advisable to strive for a consensus solution. It will take time and it will be challenging and stressful but produce the best long term outcome for the project. To be effective as a project manager also means to be personally effective. A very good start into this topic is Stephen R. Covey's "7 habits of highly effective people"

There are multiple motivation theories that the project manager should also be familiar with to determine what is most important for the project stakeholders at a given point in time. Good people skills are key to be successful in this area.

Cost Management

Project costs are closely linked to time management. In order to control the costs it is crucial to have a good time management in place. In the last post we looked at Time Management and noted that

• estimates should be done by people who do the work
• for estimating tasks/WBS we should use historical information if possible

In connection with cost management we should add

• costs should be managed to estimates (that applies also to time, scope and resources)
• a cost baseline should be kept and only be changed when an approved project change occurs
• corrective measures should be taken once we determine that we encounter cost issues

From a Project Management point of view it is important to look at cost, time and scope (triple constraint). To practice this in a real project the Project Manager should not just accept time and cost requirements from Management. The Management guidelines will set a framework. It is up to the Project Manager to confirm these guidelines or reconcile any differences. In case of differences the communications management will be a key success factor.

The following input is needed before a cost estimate can be created

• Work Breakdown Structure (WBS) incl. tasks
• Timeline (Network diagram) that shows how the project will flow from end-to-end including all dependencies
• available Resources (in-house, contractors etc.)
• Risks associated with the project (e.g. Risk Management Plan)

The output of the cost estimate should be a cost management plan.
The following cost estimating methods are common

1. Analogous estimates - Managers provide estimates based on similar projects or previous experience
2. Bottom-up estimates - Subject Matter Experts provide estimates

There are several more methods (e.g. parametric estimates, computer estimating tools, earned value analysis) to come up with cost + time estimates.
Once we have the cost estimates we can distinguish between the following types of cost:

• variable cost - cost that changes with amount of work or production (e.g. material cost)
• fixed cost     - cost that does not change with amount of work or production (e.g. car rental)
• direct cost    - cost that can be directly attributed to the project (e.g. wages)
• indirect cost  - overhead costs (e.g. taxes)

For the project manager it is important to understand how good or bad the estimates are that they get. During the initiating phase an estimate will most likely be less accurate since not enough or inaccurate information is available. This first estimate though sets the expectation and hence it is important to communicate at least if this requirement requires a large, medium or small effort. And yes, you need to specify what large, medium and small means (e.g. <=10 days development --> small).
Be careful with this first feedback. Try to understand the requirement good enough to set the expectations correctly, NOT to provide an accurate estimate.

As the project moves forward more information becomes available and the estimates need to be refined (the estimate becomes more accurate). It is up to the Project Manager to provide an overview of ALL requirements and their related estimates. At that point a prioritization will most likely be needed since not all requirements can be addressed within the projects time, cost and scope limits.

It is the Project Managers responsibility to ensure the project sponsor (and other stakeholders as needed) have phase appropriate information about costs to ensure a successful project. This requires a good communication management. Note that without good communication a lot of the other areas become less valuable. Communication is the glue that holds all project management pieces together!

Time Management

There are multiple factors that influence how a project needs to be scheduled.  One of the first criteria is how the project go-live date is determined.  

1. Do you get a go-live date from the project sponsor and/or other project stakeholders?
2. Do you determine the go live date yourself?

In case #1 it will be necessary to calculate the time backwards from the go-live date.
In case #2 it is possible to calculate the time forward.

Many project managers will use some project management software (e.g. MS Project) to do the Time scheduling. The Software is helpful but only as good as the data that is used for it. Hence the correct Task creation and the Task duration estimate are key to a successful scheduling exercise.

In order to schedule the tasks first a Work Breakdown Structure with tasks needs to be setup.Then a time estimate for each task needs to be created. The time estimate should be created by people that do the work. This is not the task of the Project Manager! To ensure the best accurate time estimate it is important to get time estimate from multiple experts.
A known issue is that projects are either scheduled

1. too aggressively or
2. too cautiously

In case #1 the estimate always assumes the best possible case. This is not realistic. Every project will encounter issues that were not planned for.
In case #2 the estimate always assumes the worst case.  This is not realistic either. You need to plan with the data that you have but expect that changes will occur.
It is the responsibility of the Project Manager to come up with a realistic estimate.

Estimates for Software Projects usually come from

• Guess from Experts (ideally from several experts independently and on smaller tasks)
• Historical project information
• Benchmarks - if available to compare with other companies

The following estimating methods are available

• Critical Path Method (CPM) - one time estimate per activity
• Program Evaluation and Review Technique (PERT) - has 3 time estimates per activity (optimistic, pessimistic, most likely)
• Monte Carlo Simulation. From a practical point of view this is the least common method.
  
  In many projects there will not be enough time to get experts to estimate all tasks with 3 estimates independently. Hence the most common estimating method is CPM. If this method is used together with historical data the estimates should get more accurate over time.
  

The scheduling tools are

• Milestone charts     - show only major events (0d duration)
• flowcharts                - depict workflow and process flow. Used for quality
• Bar (Gantt) charts  - good for reporting and control. Not recommended for planning
• Network diagrams  - shows interdependencies of tasks. Recommended planning tool (see this link for detailed information)

Another important consideration for your scheduling work is the Software Development Methodolgy that is used. For traditional big waterfall projects the scheduling can be fairly challenging vs. the scheduling of smaller junks for agile project management is easier to manage. We will get to that topic in more detail in another post.

Scope Management (High Level Overview)

This is all the work and only the work that is needed to complete a project successfully. The Project Manager needs to check constantly that all agreed upon work is completed on time. Scope Management also means that no additional work is added to the project. Yes, that's right. The objective is to give the customer what they ask for. Make sure you really understand this point in order to become or stay a successful project manager.

Projects can be selected in a number of ways and the selection process varies widely depending on Company size, Industry and some other factors

 

Example: Small Company

• Business Owner decides that a certain functionality is needed and puts a project team together

Example: Mid- + Large Companies

• Return on Investment (ROI) calculations are put together by dedicated resources to make a case for starting a project
• Management decides to fund a project based on policy guidelines from senior Management

See this link for a short, graphical overview of the different Project Selection Methods.

One key part at the beginning of a project is to define what the objective of the project is. For this purpose a Project Charter is used. Here is an example of a Project Charter .

The Project Charter should at least

• Define what the project is
• State authority levels for the project (e.g. determine budget, schedule, resources)
• Define the Objective of the project
• Explain why the project is being done
• Describe the deliverables of the project

The Project Charter should be signed by senior level management to ensure appropriate cooperation from all project team members on a project. This is necessary because the project team, in most cases, does not report directly to the project manager in a corporate structure.

Over time the project scope will invariably change. To deal with this expected change in an organized fashion a change management process needs to be setup. Select this link to learn more about basic Change Management processes.

We already discussed the requirements part that is related to scope management (see blog post from November 9, 2009).

As part of Scope Management you should also

• identify project success criteria
• Get buy-off from the stakeholders on your project charter
• Determine constraints – resources, budget, schedule, scope
• Establish unambiguous and achievable goals
• Setup the project in a Work Breakdown Structure (WBS)

Note: The potential for scope creep exists for every project. Therefore be very clear at the beginning of every project with the project charter and with your change management processes.

This requires some effort upfront but will pay off quickly through clear communication and less confusion.

Communications Management

Communication is a critical part of every project. You should proactively prepare the project communication since this can make or break a project.
Based on experience many project managers neglect this part at the beginning of a project and then struggle with communication issues throughout the project.

Example: The update process for the Project Sponsor hasn't been clearly defined at the beginning of the Project. Now the Project Manager + Team have to go through multiple trial and error exercises to see what works best. Is it an email update? If yes what is supposed to be included there? Is the Project Sponsor detail oriented or does he/she only wants a high level overview?

These communication issues may negatively impact the general working relationship between the Project Sponsor and the Project Manager/Team.  This would be the last thing any project needs.
Conclusion:  To think about these communication related challenges proactively will ensure a smoother project.

The Communication Plan should include the following:

1. Determine with whom you need to communicate. (some examples below)

• Project Sponsor
• Project Team
• other Teams
• vendors
• Sub-contractors

    2.   Determine communication methods

• formal/informal - (e.g. formal: status report, progress report, informal: phone conversation)
• written/verbal - (see above)

    3.  Determine information that needs to be included (some examples below)

• Project Status
• Milestone Status
• Priorities
• Key Issues
• Accomplishments
• Next Steps

     4.  Determine reason why communication is needed (some examples below)

• to prepare a project kick-off meeting
• to setup the Test Plan

     5.  Determine how often you need to communicate (some examples below)

• daily/weekly/monthly

     6. Determine how you should communicate (some examples below)

• face-to-face meetings
• teleconference
• email

See an Communication Plan example below

Check this link from Steven Covey's "The seven habits of highly effective people" for more info concerning communication

Quality Management (HIGH LEVEL Overview)

As the first step we need to clarify what quality is.

In a sense quality relates to all 3 parts of the triple constraint and is equally important to them. If a project is not performed on time, according to the specifications and within budget it is not considered successful. Project quality is about a project performing faster (time), cheaper (cost) and better (scope) than it is currently performing.

A more formal quality definition is in PMI's PMBOK (Chapter 8):

Project Quality Management processes include all the activities of the performing organization that determine quality policies, objectives and responsibilities so that the project will satisfy the needs for which it was undertaken.

Note that quality might be defined differently by various quality leaders and organizations.

There are several formal quality systems

• Malcolm Baldrige National Quality
• ISO 9000:2000
• SEI's Capability Maturity Model
• Six Sigma
• Lean Sigma
• Deming Prize

One important note: Quality has a price! Make sure at the beginning of a project that all stakeholders have the same understanding of what quality they want to achieve. See also this link for more info on cost of quality and cost of non-conformance

Project Quality Management has 3 process steps

1. Quality Planning
2. Quality Assurance
3. Quality Control

During these processes different steps need to be looked at and a number of different tools can be used

1. Quality Planning
    What needs to happen during this step?

• Stakeholders need to be identified and prioritized
• Project Quality standards/expectations need to be identified and prioritized

      A quality standard should be
               S   pecific
               M easurable
               A  ttainable
               R  ealistic
               T   imed

Example: Quality Standard : Every hard disk of notebook xyz will work w/o any maintenance for 24 months or 15,000 hours

2. Quality Assurance
     What is quality assurance? This activity describes who, what , when, where and how a quality standard
     will be measured.
                 
     These activites must be measurable, relevant (meaning related to the quality standard), integrated in the
     quality system and someone needs to be responsible to ensure the activities occur.
     Some tools which can be used during this step: Gap Analysis, Flow Charts, SWOT Analysis

3. Quality Control
    from PMBOK: ".. monitoring specific project results to determine whether they comply with relevant
    quality standards and identifying ways to eliminate causes of unsatisfactory results"

     To put this very simple: Is the customer satisfied with the quality? This is related to the requirements
     and quality standards that were developed in step 1.
     Some tools which can be used during this step: PDCA Cycle (plan, do, check, act) from Six Sigma
     Histograms, Pareto Charts, Flow Charts, Cause-and-effect diagrams, scatter diagrams, run charts,
     control charts

Summary: Quality Management is a HUGE topic and this is obviously only a very first glance at some of these areas.

Here some links that might help to delve deeper in this topic
Six Sigma
ISO 9000
Wikipedia - Quality Management

Risk Management Overview

Please note that I'm providing a very short and high level risk management overview here. For a deeper coverage on this topic see also PMBOK Chapter 11 (Fourth Edition). There is a ton of information on the web and it makes sense to check several sites to get a better overview.

Risk Management with regards to project management deals with project risk. A project risk is something that has a negative impact on at least one project objective. Note that typically Risk Management also includes opportunities. For this short overview though I'd like to focus on the more common understanding of project risk as described above.

Different people have different perceptions about risks. Some people want to avoid all risks and some  always assume the best and don’t see any risks. It is important to establish a common Risk Strategy at the beginning of the project to ensure a common understanding and proper use of Risk Management. The project manager should determine the priorities with the project sponsor and then update the team.

Some benefits of Risk Management are:

• minimizes issues and surprises
• decreases probability of issues occurring
• increases probability of project success

 In general we can distinguish between the following risk types:

 - Business risk - normal business risk. e.g. Business conditions changes during the project or scope, time, budget for your project is changed

- Insurable risk - This could be e.g. Tornado. The risk should be avoided or at least the impact be reduced (e.g. buy insurance)

- Known risk - e.g. not enough resources available at a particular time to achieve project objectives

- Unknown risk - these risks are always there and you will have to deal with it

To make Risk Management successfull the Project Manager as well as the Project Team has to understand, accept and use the risk management process.

Please note that the Risk management process needs to be applied during all project stages

Example:

- Business requirements are submitted

- Risk Management determines risks associated with these business requirements
- Project schedule is build
- Risk Management determines risks associated with the timeline, resources and effort Estimates

The Risk Management process contains the following 7 steps

1. Identify the risk (e.g. Expert interviews, brainstorming, questionnaires, etc.)
2. Analyze the risk (e.g. how likely is this risk?  High/Medium/Low)
3. Prioritize the risk (e.g. what is more important to you scope, time or budget?)
4. Find an appropriate response to the risk (e.g.

• Accept the risk – if the risk can’t be avoided, minimized or transfer you will have to deal with this risk
• Minimize the risk – this means reducing the probability of this risk to occur or at least minimize the impact when it occurs. It’s important to note that the risk cannot be completely eliminated.
• Transfer the risk – in this case we shift the risk to another party but we do not eliminate the risk
• Avoid the risk – in this case the risk is eliminated. This means you know about this risk and can plan to avoid it.

5. Execute the response to the risk
6. Evaluate how the execution worked (review risks regularly, e.g. review how the risk probability was impacted etc.)
7. Document the results (e.g. this will provide valuable info for your lessons learned records)

Here is an example of a Risk Management Plan

Column in Excel                                                                                    possible field values

Risk Status                                                                    open, closed

Last Review date

Risk Description

Probability of Risk                                                         High, Medium, Low

Risk Impact                                                                   High, Medium, Low – this is related to the

                                                                                     probability of the risk

Current status (compared to previous status)                  Better, Same, Worse

Risk Owner                                                                   Name of Risk Owner                                  Response                                                                       Accept, Avoid, Transfer, Minimize

Notes                                                                            Additional info’s regarding Response

Requirements Process for Business and IT related projects

Before we go back to the areas mentioned in the last post let's spend some time on the requirements process.
The requirements process is an extremely important part and hence we need to understand what needs to happen here before we go into the different project knowledge areas.

Some important notes about requirements

- Requirements need to be prioritized

  Before the project starts agree what document you want to use for the HIGH LEVEL requirements. It

  might be helpful to gather this info on a spreadsheet.

- The number of requirements needs to be controlled. If you have more requirements than you can  

   handle set a challenging but realistic requirements threshold.

   If you have a set timeline by your project sponsor keep in mind how much development time you have and

   what is most important to your project sponsor.

- Remove duplicate requirements as early as possible to ensure less confusion

   this needs to be done during the HIGH LEVEL requirements gathering in order to prevent confusion

- Ensure volume and performance requirements are clearly stated

  How many people, processes etc will use your solution? Clarify this as early as possible so that you provide

  the best possible design for the desired solution

  

- Set timelines for the requirements process and stick to it (e.g. set a requirements submission deadline)

   It's simply a good planning practice. Don't forget to add some slack.

     

- Keep the requirements document under version control

   This ensures that every stakeholder understands what is in and what is out of scope. Requires a thorough

   communication plan.

  

- Once the submission deadline has passed implement a change management process to handle

   additional requirements (new requirement submissions or changes to existing requirements)

   This ensures that the scope change fits within the time and budget expectations (if it is done

   properly)

- Ensure stakeholders have access to requirements

- Do you need any internationalization (translation) for your project? If yes, have all requirements  

   been  clearly documented?

   Ensure that you have test cases for all internationalization related functionality. This could be a translation or

   a different system behavior in another country, sub-region or region

- Ensure all Hardware, Software and communication interfaces have been clearly defined

  This is one of the Key points since the interfaces tend to cause the most issues.

- You should be able to create a use case / test case for every functionality that you develop or plan

   to use

Here some good articles on the requirements topic from Karl Wiegers

The Requirements Document should contain these area's

System Overview
1. Overview
     * Analysis
     * Assumptions, Risks, Dependencies
     * Estimated work, cost

2. Scope Requirements
     * end-to-end business flow
     * Workflow + System Diagrams
     * Impact Analysis, System contacts

3. Business Requirements

4. Functional Design

5. Data Conversion Requirements

System Design

1. Data Flow Diagram

2. Data Model

3. Integration requirements (e.g. includes Interfaces)

4. System Process (Input, Process, Output)

5. Error Handling

6. Security requirements

7. System scalability

8. Performance requirements

Test Plan (a.k.a. Quality Plan)
1. System Performance Requirements

2. Use Cases for Testing

3. Test Plan

4. Issue Handling

The next post will on November 21 and then we go into the different project knowledge areas.

Project Management - Basics for Business and IT related Projects

There are many books on Project Management and many theories what works and what doesn't work. But all this information does not guarantee you a successful project. When you consider the high project failure rates you can question how many projects are run with the necessary Project knowledge today. Here is an interesting article from Harvard Business Publishing concerning Project Management experience

In general it is a question of whom you or your management trusts to get the job done. If you're in a big company you might have to choose the consulting company that is on the approved vendor list of your organization. In many cases these will be big consulting firms that offer higher manpower and safety and also charge higher rates.
For a medium or small size company you might want to find the local consulting company that best suit your needs. These consulting companies won't offer the breadth of the big consulting companies but they are most likely niche specialists that might offer lower rates.

Whatever the answer is some key questions need to be answered before any IT related project can be successful

Some example questions:
          - Do you have resources with sufficient Project Management knowledge that can lead your project?
          - Do you have in-house IT resources that conduct the project or will you have to use external IT
             resources?
          - Did you specify and document your business requirements clearly?
          - Did you identify all the stakeholders of this project?
          - Do you have a clear picture of the Cost, Scope and Time priorities for this project?
          - Does your budget cover the necessary effort?
          - Are your business processes stable enough to justify the deployment or development of this project?
          - Do you have an idea about the expected Return on Investment (ROI)?
          - Do you need external resources on an ongoing basis to maintain the outcome of this project?
          - Do your users support the development of an IT solution?
          - Did you specifiy exactly what constitutes success for the Project?
          - Do you need deep industry knowledge to come up with the best solution or is it an added value to
             engage someone outside your industry to get new ideas?
          - Do you want to engage resources that are onsite or can you use remote resources?
          - What are your quality expectations for the Software deployment? (e.g. 99% availability etc.)

A Project should generally start with a project charter that clearly states the purpose, objective and scope of a project.  (see also this PMI link).

Once you know what you want to achieve (via the Project Charter) you will need to determine how you can get there. So the next step is to assemble the team that will execute the project. Depending on the size of your organization you might be able to pick your team members or you have to take the organizations that are on your approved vendor list.

You will have to gather requirements and document them unambiguously. This sounds simpler than it is. To get unambiguous requirements is a real challenge for any organization. You need to spend considerable time here with qualified resources that can question the purpose/benefit of your requirements. One key question to keep in mind is the Return on Investment. WHY do you do this? What do you expect to get out of this project? In one of the next posts we'll dive deeper into this section.

Once you have the unambiguous requirements you need to estimate how much effort it will take to implement them. This means you have to come up with a time and cost estimate. There are several methods on how to provide cost and effort estimates. You will also have risks related to the cost and effort estimates and you have to think about how you want to keep track of them.
One of the KEY TASKS during any project is how you plan to communicate to all your stakeholders.
This can make or break a project! All your stakeholders need to know what is going on. How do you plan to do that? What communication methods do your stakeholders prefer? email, phone, video conference, face-to-face? At that point you should think about a communication plan. The bigger the project the more important this becomes.

At this point you have a scope plan (what do you want to do), a schedule (effort estimate), a cost estimate (how expensive are the resources that you need, what non-labor resources do you need), a quality plan (what constitutes a successful project), a staffing plan (which resources and how many do you need to achieve what you want to do) and a communication plan (how do you plan to communicate with all stakeholders of your project)

In the next posts we go into the different project knowledge areas (Integration Management, Scope Management, Time Management, Cost Management, Quality Management, Human Resource Management,
Communications Management, Risk Management, Procurement Management) in more details and will provide some, hopefully useful, tips on how to master Business Management + IT projects for different organizations (Small, Medium, Large)

Project Audits - What is it? Why and when should you be interested?

Hercules Consulting LLC

A project audit is an opportunity to uncover issues and challenges that come up during the execution of a project. We use this for Business+IT projects but it can be used for any project. The project audit can uncover project scope challenges, time dela......ys or possible quality issues early in the process and therefore has the very real potential to save you money. Generally it will yield the most value when it is done early in the project because that leaves the most time to intervene if necessary. Even when it is done in the middle of the project it can help to protect your investment. The costs the Project Audit can save you is huge compared to the costs for the project audit. Considered that 60% of projects fail (see http://blog.theleadershipsphere.com.au/the_leadership_sphere/2009/03/high-project-failure-rates.html) it appears smart to monitor your investment while you can revert direction if and as needed. We recommend to seriously consider a project audit for projects above $150,000.00 The higher the project budget the more important the project audit becomes. At this point the project audit is not widely used because many companies are not aware of the potential cost savings in this area. The Audit happens in 3 steps1. Determine Goal of project audit2. Get feedback from project team (via questionnaire, interview etc.)3. Prepare Report and show recommendations to address project issues. To learn more about the Project Audit select http://www.hercules-consulting.com/index.php?pr=Project_Audit