Select Page

Categories

WEB APP OF THE MONTH - MAY 2018

Design:4.2 Stars (4.2 / 5)
Features:4.4 Stars (4.4 / 5)
Stability:5.0 Stars (5.0 / 5)

AceProject is a full-featured and easy-to-use project management system that is trusted by thousands of co-located and distributed teams for project planning, tracking and online collaboration. Powerful solution at a competitive price. Visit now!

The Project Charter – What Should Be Included

The Project Charter – What Should Be Included
By Sue Cochran, Northwest University

When you initially charter a plane, you don’t need to provide a seating chart, or list of names to the airline company. You do, however, need to know approximately how many people will be on the plane, how much the trip will cost and where you are going. The Project Charter is much like that for your project.

The Charter is a document that explains the project in clear concise wording without a lot of detail. It’s written for high level management needs. These people do not need all the detail to understand what the end goal is, how long it will take and how much it will cost them.

The project charter includes:

  • The purpose and objectives of the project in clear, concise language.
  • Requirements of the project, very high level, not much detail here.
  • Project description, a paragraph or two that explains the project.
Read the Complete Article

Risk or Constraint – Project Management Processes

Risk or Constraint – Project Management Processes
By James Clements

Risk Management is now accepted as a key ingredient in any mature project management framework and one of the key project management processes that you need to get right to effectively manage bids, proposals and projects.

One small but important part of this process is that a lot of people mix up constraints and risks during the risk analysis process. You will probably find in your risk workshops many constraints will be identified as well as risks and they require a clear differentiation and distinctly different treatment, luckily they are easy to identify if you are conscious of the difference.

As we know, a risk is something that may happen and that is why risk management processes are developed to monitor the project environment to identify their potential occurrence and treat them when and if they do occur.

A constraint however is something that will happen and as such you need to remove it from the risk register. Read the Complete Article

5 Aspects of Project Management

5 Aspects of Project Management
By Atul Gaur

Recently, I read an article 7 Project Management trends to watch on PMI’s blog. I appreciate the work done by the author as I share similar views on the issues raised by Mr. V Srinivasa Rao. My views on five most important aspect of project management are as follows:

  1. Look Beyond the triple constraintsMany times we do complete projects but still feel unsatisfied with the way the targets have been achieved. I feel the value that the project brings apart from the margin should be quantified and communicated to team members well in advance so that every body can work and achieve both tangible and intangible gains from the project. Organizations should concentrate on achieving internal deliverable (values) as much as on satisfying project stake holders by delivering the project within triple constrains. Organizations must establish procedures to ensure that the value delivered by the project is assessed, verified and improved upon on subsequent projects.
Read the Complete Article

Components of a Project Charter

Components of a Project Charter
By Anna Schäfer

Every CI (Continuous Improvement) event or project starts with a Project Charter. The PMBOK book says you start with Stakeholder identification before you make a charter.

This document is best achieved using tables in MS Word. The components of a charter can vary from project to project, however the most common ones are:

  • Date of Project Charter creation
  • Date of Revision
  • Project Manager’s Name
  • Project Name
  • Type or Commodity (product or service)
  • Project Statement (why we are doing this project)
  • Current State
  • Desired State (what success looks like)
  • Contract Expiration (if applicable)
  • Diversity Supplier Potential Opportunity (what an interesting thing to point out!)
  • Stakeholders (list who are negatively and positively affected by the project)
  • Saving Opportunity (quantify it)
  • Describe Current Process or Metrics (what’s going wrong)
  • Describe Future Process or Metrics (what the goal is, mention numbers)
  • Customers (list who the customers are, internal, external, all of them)
  • Customer Requirements (what do they expect, remember we do this for them)
  • Risks (every project has a risk, quantifiable or not)
  • Estimated Project Expense (travelling expenses, subcontracting, etc)
  • Team Members
  • Executive Sponsors (who will approve the charter and modifications to the charter)
  • Steering Committee Members (some names may cross the stakeholder’s list)
  • Project Timeline: milestone (phase 0, phase 1, etc), deliverable (example: prepare contract), status (on time, past due, etc) and due date
  • Approval signatures by phase

Anna Schäfer is currently a Supply Chain Manager working in the biotechnology industry with over twelve years experience, mostly in the aerospace industry. Read the Complete Article

Work Breakdown Structure (WBS): Top-down or Bottom-up?

Work Breakdown Structure (WBS): Top-down or Bottom-up?
By Samuel Prasad

Project Managers are always talking about Work Breakdown Structure (WBS). What is WBS and why is it needed? Simply put it is a hierarchical depiction of all tasks that must be done to complete a project. The tasks at the lowest hierarchical level define unit(s) of work that can be unambiguously defined and whose time, cost and resource requirements can be accurately computed.

There are essentially two ways to create a Work Breakdown Structure – the top-down or the bottom-up approach.

  • The top-down approach, in my opinion, generates a complete and more accurate WBS. In this approach, the WBS is derived by decomposing the overall project into sub-projects or lower-level tasks. This decomposition is based on general project characteristics and not on detailed design elements. The decomposition continues until the tasks or work units reach a level where they can be accurately defined and estimated.
Read the Complete Article

An Example of a Project Charter

An Example of a Project Charter
By Merrie Barron and Andrew R. Barron

Introduction

  • Overview of the ProjectProvide a simple but precise statement of the project.
    • Example 1Rice University is planning to create a store to sell computer supplies.
  • Purpose of the Project Charter

    This Project Charter outlines the purpose, objectives, and scope of the project. The purpose of a Project Charter is:

    • to provide an understanding of the project, the reason it is being conducted and its justification
    • to establish early on in the project the general scope
    • to establish the project manager and his or her authority level

    A note of who will review and approve the Project Charter needs to be included.

    • Example 2The Project Charter will be reviewed by the project team and approved. The final approval will be the Dean of Undergraduate Studies.
  • Project Objective and Scope Objective

    The objective of the project should “clearly stated” and contain a “measure” of how to assess whether they have been achieved.

Read the Complete Article

10 Key Principles of Agile Software Development

10 Key Principles of Agile Software Development
By Kelly Waters

Agile Development is one of the big buzzwords of the software development industry. But what exactly is it? Agile Development is a different way of managing software development projects. The key principles, and how Agile Development fundamentally differs from a more traditional Waterfall approach to software development, are as follows:

  1. Active user involvement is imperative
  2. The team must be empowered to make decisions
  3. Requirements evolve but the timescale is fixed
  4. Capture requirements at a high level; lightweight & visual
  5. Develop small, incremental releases and iterate
  6. Focus on frequent delivery of products
  7. Complete each feature before moving on to the next
  8. Apply the 80/20 rule
  9. Testing is integrated throughout the project lifecycle – test early and often
  10. A collaborative & cooperative approach between all stakeholders is essential

There are various methodologies and standards that address various aspects of software development, for instance PRINCE2 for Project Management, Use Cases/UML for Analysis and Design, ISEB for Testing. Read the Complete Article

WBS Types

WBS Types (#5 in the series How to Plan and Organize a Project)
By Michael D. Taylor

Even though the term “Work Breakdown Structure” has been used as a label for all project scope hierarchical diagrams, there are, in practice, many types other than “deliverable” oriented structures.

Verb-oriented WBS: a task-oriented WBS defines the deliverable of project work in terms of the actions that must be done to produce the deliverable. The first word in a given WBS element usually is a verb, such as, design, develop, optimize, transfer, test, etc.

Noun-oriented WBS: a deliverable-oriented WBS defines project work in terms of the components (physical or functional) that make up the deliverable. In this case, the first word in a given WBS element is a noun, such as, Module A, Subsystem A, Automobile Engine, Antenna, etc. Since the nouns are usually parts of a product, this WBS type is sometimes called a “Product Breakdown Structure (PBS). Read the Complete Article

Definition of Crashing (In Project Management Terms)

Definition of Crashing (In Project Management Terms)
By Sivaraj Dhanasekaran

Crashing is a schedule compression technique used to reduce or shorten the project schedule.

The PM can various measures to accomplish this goal. Some of the common methods used are

  • Adding additional resources to the critical path tasks
    This option has various constraints such as the securing of the budget to add the resources, and the availability of the resources.
  • Reduce the project requirements or scope
    This can be done only if the sponsor and major stakeholders agree to reduce the scope

After applying the crashing, the critical path might have changed and result in creating a different critical path. Always revisit the project schedule to ensure the schedule has been crashed.

Dhanasekaran, Sivaraj is a certified PMP and works as a Senior Project Manager in one of the leading MNC banks in Singapore. He has over 13 years IT experience and handled banking projects as well as managed production support team for complex Treasury applications for various MNC banks. Read the Complete Article

Types of Risk in Project Management

Types of Risk in Project Management
By Miley W. Merkhofer

The most common project risks are:

  • Cost risk, typically escalation of project costs due to poor cost estimating accuracy and scope creep.
  • Schedule risk, the risk that activities will take longer than expected. Slippages in schedule typically increase costs and, also, delay the receipt of project benefits, with a possible loss of competitive advantage.
  • Performance risk, the risk that the project will fail to produce results consistent with project specifications.

There are many other types of risks of concern to projects. These risks can result in cost, schedule, or performance problems and create other types of adverse consequences for the organization. For example:

  • Governance risk relates to board and management performance with regard to ethics, community stewardship, and company reputation.
  • Strategic risks result from errors in strategy, such as choosing a technology that can’t be made to work.
Read the Complete Article

Recommended PM App

Recommended PM App

Categories