• About Us
    • FAQ
    • Letter from CEO
    • Our Project Management Approach
    • News of Interest
    • Specialized Team
    • Project Office Central
  • Specialized Management Services
    • Project Oversight
    • Project Manager Mentoring
    • Project Rapid Launch
    • Project Recovery
    • Price Consulting Group (Project & Portfolio Management)
  • Case Studies
    • Project Manager Mentoring
      • Direct Sales Industry
      • Sara Aus (Project Manager Mentoring)
    • Project Planning via Project Rapid Launch
      • Government - Software Project
      • Sports Industry - Data Integration Project
    • Project Recovery
      • Banking Industry - Software Project
      • Government - Software Project
      • Healthcare - Business Process/Software Install
      • Insurance Industry - Software Development Team
    • Project Management Office
      • Healthcare - Project Management Office Installation
    • Project Oversight
      • Software Development
  • Contact Info
  • Repository
    • Articles
    • Blogs
    • PM Documents
    • PM Quick Links
    • YouTube Video
  •  

Project Management Articles

del.icio.us Digg Furl Reddit

- Microsoft Project is not Project Management! (12/07)

- Problem vs. Project Management (1/08)

- How to sell Project Management in your organization. (2/08)

- Gartner Research "Top 8 Reasons why projects fail." (3/08)

- The Struggle with Resource Management (4/08)

- Planning can't start too early. (5/08)

- Who owns the Project Management Plan? (6/08)

- Lessons Learned from a Critical Business Systems Outage (7/08 DRAFT)


Microsoft Project is not Project Management

Over the years, I have come across many organizations that believe that Microsoft Project is project management. Their project managers or business managers will spend hours first trying to figure out the software, and then to try to negotiate entering their tasks within the tool.  Here is the problem, it adds complexity, frustration, and diverts the attention from the real task at hand.  Which is managing a project.

I am of the opinion that Project is a poor planning tool.  It is to easy to become focused on the tool and lose sight of the real project.

It become a terrible planning too.  As a PMI would profess, start your project planning with a Work Breakdown Structure.  Identify the tasks, the sequence, the resource needs, dependencies and at that point  consider entering the info into project.  It is a much better tracking tool than a planning tool.  I prefer the manual processes to really glean all the information that you, your team and the project sponsors will need for successful project execution and completion.

I have pulled many PMs and client's out of the tool in order for them to see the big picture.  The purpose of project management is to plan and manage the risks associated with a project.  Not to become the slave of a tool that has some quirks that are difficult to understand.  You could spend hours trying to understand what it does and how you need to work with it.

 


Problem Management vs. Project Management

“An Emergency is a life threatening situation. What you have here is a problem.” –

 Small Business Owner

Ready, Fire, Aim!

Managers who focus on the symptom at hand tend to lose site of the “Big Picture”.  When focusing on a single situation other significant project objectives are ignored, increasing overall project risk and decreasing project efficiency and effectiveness.  Ultimately, you may be creating a solution for the wrong problem.   This can lead to increased cost due to rework, extended schedules and the possibility of missed opportunities with customers.

We have all heard the 5Ps.  Proper Planning Prevents Poor Performance. 

While most can identify with the statement, human tendencies suggest that we are more apt to act first and plan along the way or not plan at all. This is Problem Management!  When a critical situation like a stringent timeline is introduced, a client’s demand or an emergency situation often triggers a decision based on emotions and not facts.

When a Manager takes the time to understand the need, the desired solution and the steps required to succeed, Project Management has been utilized.  Project Management is a proactive approach, problem management is a reactive approach.

What is Project Management?

Project Management is the ultimate risk management technique for projects.  If your customer has expectations for schedule, budget, quality etc, don’t rely upon hope and goodwill to accomplish the projects.  Hope is not a strategy.  The more risk, the greater the need to mitigate the risk with Project Management techniques.  Some of the more commonly used project techniques include communication, scope, quality, schedule, cost and risk management. 

Project Management is about understanding where we are, where we need to go, how we will get there, who will get us there, and when do we need to get there.

Good Project Management does not lead to excessive paper work, bureaucracy, nor does it slow down progress.   In fact, good project management techniques provide the fastest most effective way to complete a project and achieve the desired result.  Without proper planning, the schedule, budget and quality of the solution is at risk.

Things to consider for every project

·         Risks need to be identified early

·         Enough detail must be  gathered to determine and develop project objectives

·         Measurements are vital to track progress

·         The less amount of time you have to complete a project, the more you need to plan

·         The more people you have involved, the more you need to communicate

·         The plan can and should change based on changing business needs


 

How to sell Project Management in your organization.

I have seen some of the best most experienced project managers fail on projects because of their organizations lack of understanding or willingness to leverage the project management profession.  The true strength and value of  Project Management tools come from the use across the project, the stakeholders and to possible vendor partners. 

If PM tools are not used by all, then the PM will end up using them in their own very small way, and will deal with the other aspects of the project in a more acceptable manner for the organization.  This environment for the experienced Project Manager that has their hands tied can end up being  a slow painful employment experience.

In short one success at a time.

The key to selling and using project management is to sell and show the value for every technique within your project planning along the way.  For instance, the use of a work breakdown structure (WBS) on projects is the backbone for all projects.  But rarely do project managers use one.  During a PMI chapter meeting I presented at recently, I surveyed the group to ask how many used a WBS to plan their project.  About 50% of the group raised their hands.  When I asked how many used and shared the WBS with their business stakeholders, no one raised their hands.  PMs are missing an opportunity to share a very simple and effective picture of the project scope.  Most business executives are very picture oriented.  To share a WBS diagram and to communicate your understanding of the project is very powerful.  It communicates your understanding of the project.  Better yet, it communicates your understanding of the project to the people who can help develop the proper understanding of the project.  Your WBS could be more wrong then right, but with the diagram that can be fixed very quickly.  With their help.  They are now leveraging Project Management!

Be ready to sell, explain, and show value for all project management techniques.  One by one your hands will be untied and the organization will begin to insist on project management techniques for all projects.

Your business sponsors will be impressed.


Gartner Research "Top 8 Reasons why projects fail." (3/08)

According to a Gartner Research Survey, the top 8 reasons for project failure are:

  1. Technology did not work

  2. System delivered did not meet requirements

  3. System met requirements, but was late

  4. Requirements had changed by the time system was delivered

  5. System worked but the users would not use it.

  6. System did not produce the expected results

  7. Benefits were obtained, but they no longer mattered to the business

  8. Failure in business change management

Most of these issue could have been mitigated with Project Management.


The Struggle with Resource Management

Resource management is the ability to know what your employees are working on, how long they work on a particular project, and when they will be free to work on the next project. By tracking project status and employee work load, management can confidently plan and schedule future project efforts. Management will have the ability to forecast future resource availability.

Sounds logical, right?

Then why do so many organizations struggle with their employees working on overload and burning out? Why are so many organizations forced to push new project start dates out and some projects never start? Why does management wonder where their employees spend their time? Employees are on work overload; they are stressed out, fed up and burnt out.

As a nation we are taking more sick time than ever before, why is that? It’s because we don’t have a handle on where employees are spending their time, and when projects will complete and the next project can begin.

Resource management is more than knowing what your employees are working on. Resource management is planning and controlling work. Understanding the timeline, budget and scope of the project and delivering the project as planned, all key contributors to getting resource management under control.

Creating a project plan is a start to organizing resources and work, but management needs to take that plan to the next level, controlling the plan.

Planning a Project

Our culture is a fast pace culture, which is why many organizations find themselves executing a project, before understanding what the project is intended to accomplish. How many times after a project starts does more information become available and the work already performed becomes obsolete?

 By taking a step back into planning a project, we can avoid the mishap of performing incorrect work and tasks, which means, resources are working on the right tasks and value added work is performed. 

 Gathering the requirements for the project and understanding the deliverables are key in understanding the project scope. It is important to understand the purpose of the project and what the expected outcome and the final results the project should produce. By understanding exactly what the project is to accomplish, managers can utilize the knowledge and expertise of their resources in scheduling the work.

 When resources are included in the planning process, and the scope of the project is defined and understood, resources begin to buy-in to the project. Having a clear vision of the project’s objectives enables resources to work on the right tasks to accomplish the project’s objectives. Managers will see less re-work when their resources are included in the planning process. Managers will also find scheduling a project will become easier when the subject matter experts (resources) contribute to the planning process.

 Once resources begin to work on the right tasks, and see how the work they are performing contributes to the success of the project, managers will have the flexibility of scheduling future projects with the knowledge that resources will be available to work on the project.

Controlling the Project

Maybe planning the project is a luxury many organizations afford, but is the planning taken to the next level, by controlling the project? Once a plan is in place, is that plan executed, or is it tossed to the side to allow for flexibility, possibly changing the scope of the project?

 Flexibility is nice.  It’s great to have the flexibility, early in project efforts, to add another field in an application. It’s great to add a new value to an options list. Yes, flexibility can be our friend, but when does flexibility become our foe?

 How about when a user has a cousin who sells a software product that relates to the project objectives, and it would be really easy to implement a few additional features now, since the project is working on similar tasks already.

 In order to control the project, and manage resources, the scope must be adhered to and additional “like” efforts, must be placed in a new project, which are planned and controlled. By controlling the scope of the project, managers allow themselves the freedom to schedule resources.

 Allowing the project the flexibility to manage what is in scope and leave out of scope items for another project, organizations will find they have control over the work resources perform and the scheduling of the work.

Tools

There are several tools available on the market, all promoting “insight to resource management”. Tools can be found to meet just about any organizations needs, there are tools that are solely web enabled, there are tools to load on the client desktop, there are tools that mix and match client desktop with web enabling.  All are viable tools, and given the needs of an organization can be used to fit those needs.  The tools all have common features and fields, and most are equipped with EMAIL capabilities to send reminder notes to resources when a task is due or overdue.

 While all the products are capable of producing resource management information, it is the responsibility of the organization to properly gather project requirements, include resources in scheduling projects and controlling project scope. Without these vital pre-planning and project controlling techniques, the information entered into any tool will quickly become obsolete, and organizations will find themselves wondering why the tool is unable to help get resource management under control.

Planning can't start too early.

Many business and technology leaders will put off planning a project until many of the definitions have been identified, slowly and over time.  Almost in some circumstances until the resources have been allocated.  An then the planning begins.  I would advocate that planning can occur once the concept is born by the executives.  While it might not require a full time effort, it can start and continue to a point where other decisions are required or until the concept has run it's course and is no longer a project possibility.  If the project goes forward, it can start quickly with a understanding of the concept, high level objectives and the basis for the framework of the solution.  If you didn't start planning until now, all of that would need to be discovered and a solutions could already be sold to a client without a understanding of what it will take to accomplish.

 

Who owns the Project Management Plan

In short, the Project Manager is responsible for facilitating and documenting the project understandings in all the project plans.  The content and detail is owned by the entire team to include the business stakeholders.

 

Lessons Learned from a Critical Business Systems Outage

I was at a Fortune 500 company back in 2004.  They experienced 3 separate but very severe system outages that shut down the business.  The first was caused by a water pipe break in a ceiling above a major data center  located in Chicago.  It took the entire IT Staff 3 days to bring in replacement hardware, to retrieve the systems from backup, and to get the systems restarted in an orderly fashion. Luckily the situation occurred on a Saturday Morning.

The company IT staff was really lucky to pull that off.  They had no plan, limited back-up data, and had never rehearsed restarting all the systems that were interrelated.

A bit of positive news from the experience. The focus of the business on business continuity received the proper priority.  Until the outage, the business had told IT that they had 48 hours to recover from a system outage.  But the priority of the processes, resource allocation and business involvement was lacking.  All that changed.  The resources, time and business dedication to business continuity increased.  We had 2 other business outages that year, both were preventable but at the same time, this company became expert in business continuity.  Instead of systems being down for days, the most the systems were down was 4 hours.

The Take Away.  

Sit down with the business executives.  Discuss with them and gain an understanding of their expectations for how much time their business operations can go without IT systems.  This is also your opportunity to set expectations in regard to the resources necessary to meet those expectations.  The faster they want systems restored, the more money it will cost.  Also, try to prioritize the systems.  Not all systems can go back on-line. 

 


Sitemap                                               contactus@internetpmo.com