Project Management

Project Termination

 

• A project can be said to be terminated when work on the substance of the project has ceased or slowed to the point that further progress is no longer possible

• There are four fundamentally different ways to close out a project: extinction, addition, integration, and starvation

 

Termination by Extinction

• The project may end because it has been successful and achieved its goals

• The project may also be stopped because it is unsuccessful or has been superseded

• A special case of termination by extinction is “termination by murder” which can range from political assassination to accidental projecticide

• Two important characteristics of termination by murder are the suddenness of project demise and the lack of obvious signals that death is imminent

• When a decision is made to terminate a project by extinction, the most noticeable event is that all activity on the substance of the project ceases

 

Termination by Addition

• If a project is a major success, it may be terminated by institutionalizing it as a formal part of the parent organization

• Project personnel, property, and equipment are often simply transferred from the dying project to the newly born division

• The transition from project to division demands a superior level of political sensitivity for successful accomplishment

 

Termination by Integration

• This method of terminating projects is the most common way of dealing with successful projects, and the most complex

• The property, equipment, material, personnel, and functions of the project are distributed among the existing elements of the parent organization

 

Termination by Starvation

• This type of project termination is a “slow starvation by budget decrement”

• There are many reasons why senior management does not wish to terminate an unsuccessful or obsolete project:

– Politically dangerous to admit that one has championed a failure

– Terminating a project that has not accomplished its goals is an admission of failure

 

When to Terminate a Project

• Some questions to ask when considering termination:

– Has the project been obviated by technical advances?

– Is the output of the project still cost-effective?

– Is it time to integrate or add the project as a part of regular operations?

– Are there better alternative uses for the funds, time and personnel devoted to the project?

– Has a change in the environment altered the need for the project’s output?

 

When to Terminate a Project

• Fundamental reasons why some projects fail to produce satisfactory answers to termination questions:

– A project organization is not required

– Insufficient support from senior management

– Naming the wrong person as project manager

– Poor planning

• These and a few other reasons are the base cause of most project failures

• The specific causes derive from these, fundamental issues

 

The Termination Process

• The termination process has two distinct parts

– First is the decision whether or not to terminate

– Second, if the decision is to terminate the project, the termination process must be carried out

• The actual termination can be planned and orderly

• Special termination managers are sometimes useful in shutting down a project

• The primary duties of the manager in charge of termination can be encompassed in nine general tasks

• Duties of the termination manager:

1. Ensure completion of the work, including tasks performed by subcontractors

2. Notify the client of project completion and ensure that delivery is accomplished

3. Ensure that documentation is complete including a terminal evaluation of the project deliverables and preparation of the project’s Final Report

4. Clear for final billings and oversee preparation of the final invoices sent to the client

5. Redistribute personnel, materials equipment, and any other resources to the appropriate places

6. Clear project with legal counsel or consultant

7. Determine what records to keep

8. Ascertain any product support requirements, decide how each support will be delivered, and assign responsibility

9. Oversee the closing of the project’s books

 

The Final Report- A Project History

• The final report is the history of the project

• It is a chronicle of the life and times of the project, a compendium of what went right and what went wrong

• The required information is contained in the master plan, all project audits, and evaluations

• The precise organization of the report is not of great concern; the content is

• Several Subjects should be addressed in the final report:

– Project performance

– Administrative performance

– Organizational structure

– Project and administrative teams

– Techniques of project management

• For each element covered in the final report, recommendations for changing current practice should be made and defended

• Equally important are comments and recommendations about those aspects of the project that worked unusually well

• The fundamental purpose of the final report is to improve future projects

 

Project Management

Project Management Processes

Project Management Processes

 

 

Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Project management is accomplished through processes, using project management knowledge, skills, tools, and techniques that receive inputs and generate outputs.

In order for a project to be successful, the project team must:

  • Select appropriate processes within the Project Management Process Groups (also known as Process Groups) that are required to meet the project objectives
  • Use a defined approach to adapt the product specifications and plans to meet project and product requirements
  • Comply with requirements to meet stakeholder needs, wants and expectations
  • Balance the competing demands of scope, time, cost, quality, resources, and risk to produce a quality product.

The PMBOK documents information needed to initiate, plan, execute, monitor and control, and close a single project, and identifies those project management processes that have been recognized as good practice on most projects most of the time. These processes apply globally and across industry groups. Good practice means there is general agreement that the application of those project management processes has been shown to enhance the chances of success over a wide range of projects.

 

A process is a set of interrelated actions and activities that are performed to achieve a pre-specified set of products, results, or services. The project processes are performed by the project team, and generally fall into one of two major categories:

  • The project management processes common to most projects most of the time are associated with each other by their performance for an integrated purpose. The purpose is to initiate, plan, execute, monitor and control, and close a project. These processes interact with each other in complex ways that cannot be completely explained in a document or with graphics The processes may also interact in relation to project scope, cost, schedule, etc., which are called Knowledge Areas
  • Product-oriented processes specify and create the project’s product. Product oriented processes are typically defined by the project life cycle and vary by application area. Project management processes and product-oriented processes overlap and interact throughout the project. For example, the scope of the project cannot be defined in the absence of some basic understanding of how to create the specified product.

Project management is an integrative undertaking. Project management integration requires each project and product process to be appropriately aligned and connected with the other processes to facilitate their coordination. These process interactions often require tradeoffs among project requirements and objectives. A large and complex project may have some processes that will have to be iterated several times to define and meet stakeholder requirements and reach agreement on the processes outcome.

Failure to take action during one process will usually affect that process and other related processes. For example, a scope change will almost always affect project cost, but the scope change may or may not affect team morale or product quality. The specific performance tradeoffs will vary from project to project and organization to organization. Successful project management includes actively managing these interactions to successfully meet sponsor, customer and other stakeholder requirements.

The PMBOK describes the nature of project management processes in terms of the integration between the processes, the interactions within them, and the purposes they serve. These processes are aggregated into five groups, defined as the Project Management Process Groups:

  • Initiating Process Group
  • Planning Process Group
  • Executing Process Group
  • Monitoring and Controlling Process Group
  • Closing Process Group.

Source: http://certifedpmp.wordpress.com/2008/11/10/project-management-processes/

Project Management

Devil’s advocate

 

I am sure all of us have come across the phrase “devil’s advocate”. In general terms this is used to identify a person who keeps on arguing against the popular choice of the majority. In a decision making process if a person is keep on arguing in favour of another alternative, when there is an obvious answer available he is referred to as a devil’s advocate. This phrase has originated from Roman Catholic church in the process of declaring a deceased person as a saint. In the process of deciding whether he is worthy to be a saint or not (a process known as canonization), the church appointed a person, to argue against. His job was to look for negative aspects of the candidate’s character and prove that he is not worthy of recognising as a saint.  This function is now known as the promoter of justice.

In management studies, there is a debate among groups about the effectiveness of having a devil’s advocate in a team, when making a decision. Some say this improves the decision making process and especially brings out creative alternatives. The counter argument is that it makes a negative impact on the team since it brings in endless arguments. I agree with the first argument since it prevents a group from coming in to conclusions without considering all the available options. I am a firm believer of this and I try to implement the same as much as possible. However this is a very painful process and needs the commitment of the whole team especially the leader. Many of the times the process could end up with unpleasant arguments so the leader needs to be aware of all possible outcomes and act accordingly.

According to IMC (The Institute of Management Consultants) USA, a similar process could be adopted to review a project plan or a proposal. A person / group called as a “murder board”  or a “read team” can be used to review a project plan to identify possible break points of the plan. Obviously this is more applicable for larger complex projects involving multiple disciplines than a simple project. I will write about how we can use this concept when planning a ECM project in a separate post.

If you haven’t experienced this yet, wouldn’t it be an interesting challenge for you to be a devil’s advocate and experience the difference ?

 

Source: http://www.experts-exchange.com/blogs/amila_hendahewa/B_2312-Devil-s-advocate.html

Project Management

Work Authorization System

Work Authorization System

Work Authorization System: A work authorization system is a method used in conjunction with project management. The work authorization system is used by the project manager and his or her designees in order to approve all project work throughout the course of the current project management venture. The work authorization system is sometimes referred to as a “WAS.” The work authorization system will typically be in the form of a list of formally adopted and well- documented procedures. Work authorization procedures specifically detail who may authorize work to be completed and how those authorizations may be obtained. These procedures will include which documents must be completed prior to work being initialized, and whether there are any other prerequisites to work being performed at any particular level during the project. To better assist the efficiency of project management in larger projects, work authorization systems also sometimes detail the timeline of the project. For instance, the work authorization system might include at which points in time certain portions of the project should be completed, in which order those tasks are to be completed, and by whom.

This term is defined in the 3rd and the 4th edition of the PMBOK.

Related Entries:

  • Work Authorization (Method) It is important for those in charge of project management that they are aware of how they convey the work…
  • Work A great deal of work has to be done to be successful in the area of project management. Work can…
  • Project Work See work This term is defined in the 3rd edition of the PMBOK but not in the 4th….
  • Work Package A work package is a portion of the work breakdown structure that allows project management to define the steps necessary…
  • Statement of Work If you are looking for ways to ensure that your products or services are guaranteed and that a client is…
Project Management

Great Businesses Don’t Start With a Plan

Source:

Great Businesses Don’t Start With a Plan

You want to start a business. So you need a plan, right? No. Not really.

As part of the research for a book I’m co-authoring — Heart, Smarts, Guts, and Luck, due out in August from HBR Press — my colleagues and I interviewed and surveyed hundreds of successful entrepreneurs around the globe to better understand what it takes to be an entrepreneur and build a really great business. One of our most striking findings was that of the entrepreneurs we surveyed who had a successful exit (that is, an IPO or sale to another firm), about 70% did NOT start with a business plan.

Instead, their business journeys originated in a different place, a place we call the Heart. They were conceived not with a document but with a feeling and doing for an authentic vision. Clarity of purpose and passion ruled the day with less time spent writing about an idea and more time spent just doing it.

It’s not that all planning is bad. It’s that efforts to write the “perfect” business plan usually lead to being precisely incorrect rather than approximately correct. One problem is that the content that most people focus on in business plans has little to do with the reality that will actually emerge. Many start-up plans emphasize some gigantic potential market and how getting just the smallest sliver of it will make them and investors rich. A colleague of mine offers the hypothetical example of selling a bar of soap for a dollar every month to just 0.5% percent of the people in China. It’s nearly a $100M business! Good luck making it happen, though.

At a business’s inception, resources are limited, and the best content for a business plan is real-world data based on testing aspects of the concept. These experiments need not be complex. You want simple, iterative tests that are easily measurable and let you know whether you are winning or not.

It’s not just start-ups. The strategic architecture of any business should incorporate facts from real world testing to allow one to adjust course as necessary. This is what Henry Mintzberg, a seminal figure in competitive strategy theory, once described as “emergent” or “evolutionary” strategy. My business partner Mats Lederhausen (formerly global head of strategy for McDonald’s as well as former Executive Chairman of Chipotle) has his own saying for it: think big, start small, then scale or fail fast.

So don’t worry too much about a business plan. But to guide your thinking, improve a pitch to prospective investors, or better align your teams, consider these design points:

1. Identify and clearly articulate your Heart and purpose. Whether you want to call it vision, Heart, purpose or calling, be very clear on the why of a business — the bigger goal at hand.

2. The team is more important than any idea or plan. The top three priorities should be people, followed by people, and then people.

3. Think big, start small, then scale or fail fast. Per Lederhausen’s advice, set the right first “start small” milestone; it will usually involve seeing people’s willingness to buy or at least try your product.

4. Focus on a well-defined market sub-segment or niche. At least to start, think of where you can potentially be the best. This strategy is almost always more successful than being just another player in a massive market.

5. Understand your business model. How you will make money is more important than pages of Excel showing financials that are simply too hard to predict at this early stage anyway. Understand instead the basic way you will make money – is it through transactions, advertising, subscriptions, etc?

There appears to be a perennial market for how-to classes, books, and templates that promise almost “color by number” instructions for populating business plans. While aspects of those tools are helpful for a structured approach, they are more likely to mislead because of their emphasis on completing the plan of a business before uncovering its soul and demonstrating whether others connect with it. People feel a sense of accomplishment upon completing their plan, but what does that plan really get them? Filling worksheets can never replace zeroing in on the passion and purpose of your business. That Heart has to be there day one. The most researched business plan holds little value without a genuine Heart behind the idea and the Guts to just get it going.

Source: http://blogs.hbr.org/tjan/2012/05/great-businesses-dont-start-wi.html

Continue reading “Great Businesses Don’t Start With a Plan”