Sunday, December 26, 2010

Project Management Made Simple

Other than the Charter, lessons learned is probably the other most neglected part of a project. It is reasonable to think that since projects are new there will be unanticipated obstacles that you run into. Those obstacles, no matter how small, will somehow be resolved. Lessons learned is your opportunity to capture what the Subject Matter Experts learned to resolve or look out for when working on the project. These should be documented and given to management, as well as kept for yourself. From a reasonableness perspective, you may manage a project in the future that has similar characteristics of the project you just finished. How inefficient would it be to drive a project team into the same issues and obstacles that you already encountered and make the new team come up with their own resolutions? Lessons learned becomes the project FYI that can help a new project team plan better and be more efficient because they are aware and have planned for certain obstacles ahead of time. All this because you were wise enough to capture this information from past experience.
In conclusion, while there is much more to formal project management and the memorization and application of proven methodologies, it is the author’s hope that this will benefit you to some degree and that maybe you will even have a take away to apply to your own project. I wish you all the best in your project management endeavors.

Read full article at:
Project Management Made Simple - PM Hut

Saturday, December 18, 2010

Ten Ways to Stop Scope Creep in Your Web Design Project - PM Hut

Let’s face it, web design is not a very predictable service. Sure, the extent of the service is to furnish a working web site (one would hope) along with any hosting and maintenance needed to keep it going. The issue is that the specifics of the project change with almost every client interaction.
Keep in mind this isn’t a problem. Web design must be a flexible and fluid service that changes to the varying needs of the client as well as the quick pace of the internet. What is a problem is scope creep.
Scope creep occurs when a client keeps piling on requests for additions or changes to their project that are outside the scope of the project. Some clients are mindful of this and will explicitly ask if it will cost more. Others, unfortunately, are not this considerate or knowledgeable enough to know when they’re pushing it.
How can you combat scope creep? I don’t think you’ll ever get rid of it completely, but there are some ways to prevent and reduce it.
Read full article by Chris LeCompte for PM Hut:
Ten Ways to Stop Scope Creep in Your Web Design Project - PM Hut

Enterprise Risk Management and the PMBOK - PM Hut

Enterprise Risk Management is a term used to describe a holistic approach to managing the risks and opportunities that the organization must manage intelligently in order to create maximum value for their shareholders. The foundation for the approach is the alignment of the organization’s management of risks and opportunities to their goals and objectives. One of the keys to this alignment is the “Risk Appetite” statement which is a statement encapsulating the direction the Board gives management to guide their risk management methods. The statement should describe in general terms what kinds of risk the organization can tolerate and which it can’t. This statement plus the organization’s goals and objectives guides management in the selection of projects the organization undertakes. The statement also guides management in setting risk tolerance levels and determining which risks are acceptable and which must be mitigated.

Read full article by Dave Nielsen for PM Hut:
Enterprise Risk Management and the PMBOK - PM Hut

Wednesday, December 15, 2010

The Project Support Office and Risk and Issues Administration - PM Hut

The Project Support Office and Risk and Issues Administration
By Richard Morreale
Risk and Issues management is one of those things that we know we need to do but in a lot of cases we don’t seem to have the time to do it well. So what do a lot of Project Managers do? They give lip service to it. They put a Risk and Issues list together and every now and then they update it but in between the updates they really don’t have the time to manage the list.
As an aside, another thing I find is that there is usually a big discussion about whether something is a Risk or an Issue. From a Project Management standpoint, who cares? Some action is going to have to be taken whether it is a Risk or an Issue and you just need to make sure that the action is taken. How do I do it to make sure that it gets done?
I assign administration of the Risk and Issues Management System to my Project Support Office.
The Risk and Issues Management Systems must cater for:
  1. The initial identification of the Projects Risks and Issues. This is usually done in a workshop attended by all of the applicable stakeholders and facilitated by the Project Support Officer.
  2. The analysis of each Risk and Issue. Each Risk is analyzed in terms of its impact and the probability of it happening. Each Issue is analyzed in terms of its impact on the Project if not taken care of and its urgency. I like to use a scale of 1 to 4 in both evaluations with 1 being low and 4 being high. Both numbers are multiplied and you come out with a single score for each Risk and Issue. I then pay particular attention to any Risks or Issues that score 8 or over.
  3. A discussion and agreement of what actions must be taken to mitigate the Risk and handle the Issue and by when the actions must be taken.
  4. Monitoring of the actions by the Project Support Office to ensure that the actions are taken.
  5. Reporting to the Project Manager and the Project Team on the Risk and Issues status for review at each Achievement Meeting.
  6. Continued identification, analysis, etc. of Risks and Issues during the life of the Project.
Assigning the Risk and Issues administration to the Project Support Office will be a big help to you and you can be assured that someone is focusing on the management of them.

Tuesday, December 14, 2010

John Isaac: The Passion of a U.N. Photographer

How this former photojournalist went from shooting the dark side of humanity to capturing the radiance of the world's wildlife.

John Isaac: The Passion of a U.N. Photographer | Photography - Offers Camera Reviews and Exclusive Photo Tips

The Impact of Energy on Projects

A very interesting article by Christie Dowling, Alexandra Gerbasi, and Vic Gulas

It’s no surprise that success in project-based organizations is driven by how well project teams perform. The quality of performance depends not only on the demands of the project but on the team makeup and dynamics. In fact, those human factors can have a much greater impact on results than the challenges of complexity and scope. Collaboration, communication, leadership, and effective knowledge sharing are vital to success, and the “spirit” of teams matters at least as much as their technical skill.


7 Things you need to pass the PMP exam

The Project Management Institute (PMI) has developed a set of criteria and credentials for recognizing Project Management Professionals (PMPs) worldwide. The credentialing process is fairly rigorous, including: three to five documented years of work experience in project management, 35 hours of project management related training, and successful completion of the multiple-choice PMP Exam. The amount of material on the PMP Exam is vast and can seem overwhelming, but don’t be intimidated! Having and using the 7 items in this article will ensure you are prepared to meet the exam head-on and achieve optimal results both on exam day and in your future career.

Read full article:

7 Things you need to pass the PMP exam

Monday, December 13, 2010

How to create a Project Charter

The purpose of a Project Charter is to document the vision, objectives, scope, deliverables, organization and the implementation plan. It is important to set the direction and ensure that you obtain the buy in from all the stakeholders. The project charter will also help with managing the project scope.
To create a project charter, you need to follow the following four steps:
  1. Project vision, objectives, scope and deliverables The first step is to define the vision. This states the purpose of the project and defines the end goal of the project.
    Based on the vision, you must document the objectives of the project. These objectives describe what must be achieved by the project. You can use the SMART (Specific, Measurable, Achievable, Realistic and Time-bound) way to describe them.
    When you have documented the vision and objectives, you can then document the scope. The scope will describe the boundaries of the project by describing how the business environment will be changed when delivering the project. This must include what is in and what is out on the project.
    Once you have documented the scope, you can then document the deliverables that will be deliver.
  2. Project organization
    In the organization section, you will identify how the project will be structured by describing who the customers are, the stakeholders and there different roles, everyone’s responsibilities and reporting lines.
    The customer is the person or entity that is responsible for agreeing the deliverables and signing of and accepting the deliverables when they are completed.
    A stakeholder is the person or entity who may have a specific interest in the project. This could be people or entities directly involved in the project, such as the project owner, project manager and team members, internal to the organization such as the CEO, Financial Director who needs to provide financial resources or external entities such as other organizations or governmental departments.
    You then list every key role involved. These may be the Project Owner, Project Sponsor, Project Board and Project Manager. You must also provide a short summary on the responsibility of each.
    Once you have documented the full project organization you can then include a diagram depicting all the different project stakeholders and the links and reporting lines between them using a Project Organization Chart.
  3. Project implementation
    You should now be in a position to describe the implementation. This must include the implementation plan, milestones, any key dependencies and a resource plan.
    The implementation plan will include all the phases, steps and activities of the project and can be created in an Implementation Plan. This may provide the Stakeholders with confidence that the project has been thought through thoroughly.
    Now you should be able to create a detailed resource plan for the project, which must include all resources, including people, finances, equipment and materials.
  4. Risks and Issues
    As a final step in the project charter you must also document the risks and issues that are know at that specific time of the project. You can also include any constraints and assumptions for the project.
And there you have your project charter. The benefit from creating a project charter is that it will help you manage the scope and ensure that you deliver consistently on time and within budget.

Article written by Petrus Keyter

Thursday, December 9, 2010

You need a Translator on your Project Team

Translators have a unique role during projects. Many project leaders try to satisfy this role themselves or allocate it to a less than capable person. This is not a good idea as it’s not about just knowing the langue of both parties. Understanding both environments and noticing the spoken and un-spoken components of a message are equally important. Plus, the bigger the communication gap the more experience at translating is required.

Read full article at:
You need a translator on your project team

Monday, December 6, 2010

Functional Managers acting as Scrum Masters: Not a good idea

By Johanna Rothman

I often meet people who are transitioning to agile, and they decided to pick Scrum, because it’s a helpful project management framework. Ok, that makes sense. But then they decide that they no longer need project managers, and that the development manager can act as the Scrum Master.
The Scrum Master is not a management position. The Scrum Master protects the team’s process and removes the team’s obstacles. For me, the Scrum Master is analogous to the project manager. (I’ve never believed in command-and-control Project Managers.)
There is still a need for managers, but a little differently. I don’t see the need for functional managers. The agile team needs a manager who champions that whole team. That means that the champion managers need to understand all the functional parts in the team, so they can help each team member.
But the real issue is that it’s a bad idea to have a manager be a Scrum Master. Here’s why:
  1. The Scrum Master is a part of the team, and the manager, because of his/her titular authority can never be a part of the team.
  2. People are reluctant to take a risk in front of their managers. (Bob Sutton in Weird Ideas That Work: How to Build a Creative Company cites data about this.)
  3. Managers set direction, which is more strategic work. They do this with managing the project portfolio, looking at the makeup of the teams, seeing if they need more people. Scrum Master work is tactical, about the day-to-day work of the project team. If you have to choose between strategic work and tactical work, which one will win? (Tactical, all the time.)
So what does happen to the managers when an organization transitions to agile? They help teams self-organize. They manage the project portfolio. They provide feedback and coaching. They champion the team. They take the lead on hiring.
Managers, do your management job. Project teams, including the Scrum Master, do your project work. The two types of work intersect above the project, not in it.

A Complete Guide to Closing Projects

Why ‘Close’?

By definition, a project has a start and an end. So it’s vital that each of those key milestones is properly planned and managed to achieve optimum success. With the project management industry growing rapidly and on a steep learning curve, it’s more important than ever to pay attention to how assignments end. Many organizations don’t manage closures well. It’s usually because they don’t include the process in the initial plan.

Key Elements of Project Closure

There are a number of key elements to project closure. The level of detail and sophistication of each depend on the organization’s size and the assignment’s complexity.
The key actions involved in close-out are:
  • Identify lessons learned
  • Review and document
  • Archive records
  • Recognize outstanding achievement
  • Disburse resources
Read full article by Michael L Young:

Closing projects