Login access is only available to associates and administrative staff.

The Emergence of Business Project Managers; Not Just for IT Anymore…

  • By: Sarah Eisan on 25 Jun 2014

Once upon a time Project Managers and IT Departments went hand in hand; Project Managers tended to be IT Professionals who over the years became very knowledgeable and respected in their areas and the natural progression was to become an IT Project Manager.

With the rapid advancement of technology, IT Project Managers have become an integral part of many companies, so much so that many companies wouldn’t dream of implementing a new system or technology without a trusted Project Manager leading the way. Many senior business leaders have quietly been taking notice of the Project Managers keen ability to create order from chaos, deliver complex projects on time, within budget and within scope and have been thinking about how these skills could help their own departments succeed…

Therein lies the emergence of the Business Project Manager. Senior business leaders are finding these Business Project Managers in their own mid-level leaders, business subject matter experts or employees who naturally demonstrate the key traits of a successful Project Manager. Often these people are sent on professional development courses to formalize their Project Management skills or they learn on the job from others already in similar roles and begin leading less technical projects in their departments such as process re-engineering or preparing to take on new market segments.

My own company has recently expanded on this practice to reach out to business leaders to ask if they would like to loan high performing employees to us to receive on the job Project Management training, then returning back to their own departments. This unique opportunity will provide sharing of knowledge and skills throughout the organization, provide internal employees with a new career development option and should make running projects in these departments easier because they now have a better understanding of what goes into running a successful project.

Does your company have Business Project Managers? If not, what are your thoughts on this? If yes, how is it working?

I’d love to hear your feedback…

Why, Why, Why… The Professional Equivalent of an Annoying Six Year Old

  • By: Sarah Eisan on 18 Jun 2014

Do you remember being six years old curious about everything? I know my 2 six year olds are constantly asking ‘why’ and according to my parents, so did I. Just yesterday, pulling into the gas station I hear:

Why are we stopping here?
Me: We need gas
Me: Because the car is low on gas and we won’t make it home without it
Me: Because cars need gas to drive
Me: Because that is the way they are designed
You can see where this is going….

Being a Business Analyst is often the professional equivalent of being an annoying 6 year old child and I’m sure our stakeholders sometimes views us with the same annoyance as a parent; but, if the 6 year old was expected to design a new car or find an alternative to using gas to power cars, then they would need to ask these questions just as a Business Analyst would when determining business need.

When conducting Enterprise Analysis, trying to determine the business need or root cause of the problem, asking why is often the best tool a BA has, specifically the ‘5 Whys’. The first time I heard about the 5 whys was when I started my second BA position with a new company whose technology and practices I was completely unfamiliar with. Coming from a place where I was a business SME in addition to a BA, the unknown of this new company was very unsettling; a mentor suggested I use the 5 why’s to determine the business need for a project I was just assigned. The 5 why’s was a new concept to me and when I swallowed my pride and asked what this was, I learned it’s the simplest yet often a difficult skill for some BA’s to master, asking why repeatedly (often 5 times but not always) until you are convinced you have identified the actual root cause and business need.

Asking why is the easy part but asking why several times when each time the stakeholder thinks they answered your question and looks annoyed with you for not being satisfied with their answer can be tricky to master. Personally I found this approach painful the first few times I tried it and I often gave up after 2 or 3 whys because I quickly became insecure… I’m the professional Business Analyst here to help solve a problem and I can’t seem to understand what the problem is, maybe I’m not so good at this after all, I began to think and I gave up on this technique. About a year later I was working on a time sensitive project where taking the time to uncover the business need through other methods simply wasn’t an option and I remembered my past experiences with the ‘whys…’ I forced myself to step out of my comfort zone and pulled the whys back out of my BA toolbox and to my surprise, it worked! Yes it was uncomfortable it at first and yes I felt like the stakeholder was judging my intelligence asking why so many times but at the end of our meeting, I truly understood the business need root cause and the stakeholder also had a better understanding of what they truly needed as well; in a 1 hour meeting, I accomplished what had previously taken several meetings. I can’t say using this tool has always gone this smoothly, there have been times when after a few why’s the stakeholder was stumped and couldn’t answer my questions which was a little awkward but it allowed us to quickly identify that the right people weren’t at the table and prevented time from being wasted.

Do you use the 5 whys in your enterprise analysis activities, embracing your own inner annoying 6 year old child? If not, what is your go to technique for defining business need and root cause?

The Beta-Bistro Project – An Introduction

  • By: pcadmin on 27 Jan 2014

Over the past 20 years I have participated in and/or have been the lead on several different types of projects. Large and small cultural and sporting events, humanitarian fundraising efforts, database work, creating legislation, business plans, web development… to name a few.

This week I was hired to project manage the opening of a new restaurant. Something totally new for me in many respects, but as I am discovering more and more each day, a project requiring similar project management applications I have used or considered using in the past. We will explore these in this Procept Weblog series in the weeks to come.

Some of my major deliverables are to hire a General Manager and an Executive Chef, oversee the design and manage the renovation, coordinate all the activities and people involved in the project.

ribbon cutting restaurant

For the purposes of this weblog series the name of the restaurant will be called the “Beta-Bistro”. The restaurant is located on a very popular pedway in a historic city in Atlantic Canada. I will be responsible for delivering the end product on budget, on time – May 1st, 2014. The project is real, but I am using a fictitious title to ensure I am not making premature announcements (via the magic of Google ) with regards to the marketing strategy under the real name.

I will be posting project updates periodically on this Procept weblog, pointing out challenges and sharing solutions. I will be ‘thinking out loud’ and hopefully tell a story that relates to the ups and downs of project management from my own experiences as someone learning along the way.

I welcome your ideas, comments and input and look forward to documenting this brand new experience.


Cynthia King
Project Manager

Total Float vs. Free Float

  • By: pcadmin on 04 Oct 2013

This is the fifth in a series of posts on commonly confused terms for the PMP exam.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) defines:

Total Float: The amount of time that a scheduled activity can be delayed or extended from its early start date without delaying the project finish date or violating a schedule constraint.

Free Float: The amount of time that a scheduled activity can be delayed without delaying the early start of any successor or violating a schedule constraint.

Total Float is calculated using the formula LF-EF or LS-ES.  The activities with 0 total float are critical path activities. So, in the above network diagram, A-B-C-G is the critical path and the total float for each of the activities on critical path is 0. The total float on non-critical path activities are D-8, E-8, and F-2.  As is obvious from the above network diagram, critical path represents minimum project duration (assuming no resource constraint) and delay in any critical path activity will cause project delay.  A positive value of total float on non-critical path activities states the activity can be delayed by the value of the total float without affecting the project’s schedule.  For example, activity F can be delayed by 2 days without effecting the overall project schedule of 15 days.  Do keep in mind, total float is most often refer to simply as “float” or “slack”.

Free Float is calculated using the formula ES (successor activity) – EF – 1 (or ES (successor activity) – EF when starting the critical path with 0). Read our blog post on Critical Path Calculations – Starting at 0 or 1 for a detailed discussion on this topic.

So, free floats for activities are D-0, E-8, and F-2. Can you see a clear pattern here? Free float is only available when two of more activities converge, in the above diagram C, E, F converges to G.

Outside the scope of PMI and PMP preparation, float has some very interesting applications in real life contracts. Other than to provide flexibility in the schedule and resource levelling opportunities during project planning, there has been a long standing debate in construction/engineering projects on who owns the contractor’s schedule float – the owner or the contractor.  Based on most US court decisions on such disputes, float is a shared resource meant to be used by whosoever needs it first. On the other side of this argument is the contractor’s view point who creates and manages the schedules and uses float for risk mitigation. In a specific case, if an owner were to use a float and a major risk were to occur later, the contractor will not have any buffer and may suffer economic losses or pursue litigation. And, so the argument continues……

Your comments are welcome!

Project Management Institute (PMI). (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (5th ed.). Newtown Square, PA: Project Management Institute.

PMBOK® Transition: 4th to 5th Edition

  • By: pcadmin on 01 Oct 2013

With more than 100 new pages,the addition of planning processes, a new Stakeholder Management knowledge area, and supporting revised PMP and CAPM exams, the new PMBOK® Guide 5th edition is a major update. Keith Farndale hosts this webinar which takes a practical approach to describe the new content and structure of the PMBOK® Guide.

The Fundamentals of Project Management in a Technical Environment

  • By: pcadmin on 15 Aug 2013

Guest post by Mr. Robert Mattia, A.Sc.T.

In today’s world of ever increasing speed, complexity and competitiveness we as Technicians and Managers find ourselves with the overwhelming need to achieve absolute efficiency. This need forces us to organize and direct our energies in more creative manners. As we surpass one goal, another sets the bar even higher requiring additional improvements. This efficiency is generally a result of taking our experiences and lessons learned and converting it into an improved method or product at the most competitive cost.

Project Management helps bring efficiency to our technical challenges. Originating in the days of pyramids and castles, Project Management has advanced through NASA and the Space Program onto modern construction processes and into the worlds of IT and manufacturing. PM is achieving a maturity in virtually every industry requiring products or deliverables. In many organizational environments the term Program Management is used to define the management and prioritizing of a multiple of projects, not to be confused with Project Management.

At some point in our careers we have all been involved with, been made aware of, or practiced the principles of Project Management. It is largely defined as the process whereby you are called upon at the inception of a project or deliverable, to plan, co- ordinate and control all the resources required to complete the project or deliverable through to operation within an allotted time, an agreed budget and to a specific level of quality and safety, at a minimum of risk.

In the early stages of our careers or as specialists, many of us play a role in the overall Project Management process. A project team may have participants exhibiting planning skills; other members of the team may have more technical or quality skills. Generally one individual acts as the Project Manager overseeing the entire process and holding ultimate responsibility and authority. It is human nature to appoint a leader. This position is usually achieved after years of playing several roles in the PM process gaining knowledge and experience or through formal education. Occasionally a Project Manager is assigned this duty at a premature stage in his career development which can produce less than acceptable project results. It can also leave the Project Manager disillusioned and wrongfully perceived as an underperformer when in fact a lack of skill sets was the true culprit.

There are countless volumes of literature available to help detail and define the need and application of Project Management techniques and methods. Many organizations have adopted PM principles and created Procedures for their own unique circumstances.

In these short pages we wish only to highlight the basics of PM and how it relates to our daily work assignments as participants of a project team.

Why use Project Management?

As with any task, it makes good sense to create and follow a well thought out game plan. PM helps create that plan. It helps you focus on your objectives by documenting your requirements and building your deliverable on paper before committing expensive and scarce resources to it. PM produces information which increases your level of confidence and communicates the expectations. It forces you to plan your resources, and then use them efficiently and productively.

The Project Management Institute founded in 1969 is the custodian of A Guide to the Project Management Body of Knowledge (PMBOK Guide®)[i]. This document represents years of effort and standardization in the Profession of Project Management. Through education and practice one can achieve the recognized designation of Project Management Professional (PMP®)[ii].

Projects can range in size and scope from a new product such as a pipe fitting to a major industrial construction project such as a nuclear plant. Each deliverable has its own unique set of circumstances. They can be standard products with multiple quantities or as in many cases a custom application. Regardless of how unique the project is, in general all undertakings require some form of control and organization.

Project Management is made up of many organizational competencies, however, we will deal with the following six main controls, once mastered will deliver a high incidence of success. These are not in order of importance or significance. Each unique project will have a set of circumstances that will dictate what priority this list should follow.

  1. Scope
  2. Time
  3. Cost
  4. Quality
  5. Resources
  6. Safety


1. Scope

A scope of work defines what it is you want in detail through written documents or an electronic data base. It further serves to avoid interpretations. A well defined scope provides clear instructions understood to mean the same thing by all who are affected by it. The Product Scope is the “What” and the Project scope is the “How”. A scope can also help to define the work breakdown. The work breakdown reduces the scope or project to easily definable and manageable parts that can be resourced and scheduled. The scope of work or a work breakdown is specific, measurable, attainable, realistic and constructible. Tender documents generally begin with the scope of work. It should address all the major aspects of a project such as time, cost, quality and safety. Generally the more detail found in the scope of work the more efficient the cost and time will be in executing it.

2. Time Control

Schedules are created to plan, monitor and control that precious commodity, time. The scope of work is usually accompanied by a time restriction. This can be in a macro form or a more detailed micro form. Several forms of time control exist. The worst form of time control being memory or as many of us veterans recall, on the back of a cigarette pack or napkin. More effective methods include lists with dates, day-timers and notes. Modern software now allows us to utilize time scaled charts, specialized computer applications and risk analysis programs.

In essence time control involves establishing a timeframe or duration and applying it to an item of work breakdown or activity. It should be measurable so that at specific intervals progress can be determined against the base or original plan. These durations are assigned by the use of actual data from previous results or from estimated results. These activities are then linked to other activities via dependencies. These dependencies are called relationships. Activities can be linear or in series or they can be in parallel with one another. By creating this network of interdependencies a critical set of activities emerges which helps to determine priorities. With accurate input of actual progress the schedule acts as a tool to determine current status and predict future results.

3. Cost Control

Similar to time control, cost control assigns value to the scope of work. Individual items within the scope can be valued and then summarized to a work breakdown item or cost code. Ideally, time control and cost control should support the same basic work breakdown structure thus providing a basis for measure. This basis serves as the initial cost plan. The value or cost of an item of work can be determined by using historical data, estimated results or through research analysis. Cost is generally broken down into labour and material with possible contingencies where they apply.

Controlling costs involves careful procurement and assignment of resources and materials within the scope budget or estimate. Any deviation from the scope or changes in work is a major source of cost overruns. Change management becomes a key function in controlling these unplanned costs. Comprehensive documentation is the basis of a well managed cost and change control program.

4. Quality

Quality can be defined as the ability of features and characteristics of a product or service to satisfy stated and implied needs.
This takes on a more technical approach to the management of work and the level of expectations in product or process. A good quality program starts with a well defined need through clear and concise scope documents, specifications and drawings. It includes such factors as material specifications, dimensioning, tolerances, welding procedures, codes and regulations. In the case of personnel it involves levels of skill, expertise or, certification and professional designation. Quality programs should be recognized and uniform. Many organizations have adopted recognized international standards of quality control such as ISO. Quality involves inspections and the documentation of results which are compared to the specified needs, which may in turn lead to non conformance and corrective actions. Needless to say the fewer non conformances encountered the more successful the project in terms of cost and time.

5. Resources

Resources include all the elements required to execute or deliver the project such as labour, material, money, equipment, tools and time. It involves procuring and assigning these resources at the point of need in the project in order to avoid waste or delay. Resources introduced too early, too late or inadequately become inefficient or non productive thus driving cost and time beyond the plan or budget. The key to efficient use of resources is to determine the optimum quantity and applying them at the optimum time. Procurement of resources, managing, human and labour relations also become key functions in a project in order to ensure adherence to quality, time and cost. Resources too can be planned in the same manner as cost and time applied to items on the schedule. By applying resources to the schedule, histograms and cumulative curves are generated providing early resource management capabilities.

6. Safety

As a mature, industrialized economy and society we have developed safe guards to ensure that people can work at their vocation with a level of confidence in their personal safety. Today, unfortunately there continues to exist economies which lag behind in basic worker safety practices. Eventually education will help to create a global minimum safe work standard.
The goal of a safe project is to perform and complete the Scope of work within a specified time, cost and quality without injury or incident. This begins with a complete safety policy and procedure. The policy and procedure adheres to or exceeds Government regulated standards of safety. These policies and procedures must be communicated to all the project participants via several media methods. These include orientation, training, regular reminders, visual and audio awareness techniques. Safety records and reporting are an integral part of a good safety program which generates statistics and lessons learned thus injury avoidance. Safety audits to ensure compliance are a must as complacency can easily result in an injury to a worker. Another widely used safety technique is the Task plan which documents the task process and highlights the potential dangers and the techniques used to avoid or reduce the risk of injury. Each participant in the task reviews the documented plan and acknowledges his understanding prior to the work. This communication helps to unify the group’s responsibilities and identifies the expectations.

To achieve a competitive edge it is necessary to take an organized approach when embarking on a project. Project management can help to achieve that success by providing techniques and guidance through each stage of a project’s development. Each of the above controls does not act alone. They each relate to one another in a project. If one of the controls is not managed adequately it will manifest itself on some other control item. For instance a badly defined scope will increase costs and duration due to excessive contingency allowances. A poorly executed safety program can result in serious injury which produces emotional and tragic results but also causes resource inefficiencies and increased costs or time delay. Conversely poor quality or product can force a project into reworking non conformances utilizing additional unplanned resources.

In conclusion it makes good sense to consider the Fundamentals of Project management in your assignment. When a project is small in nature a Project Manager may be on their own to perform all the major functions of control. On larger projects the function of the Project Manager may be leader and coach guiding a team of experts. Utilization of Project Management does not guarantee perfect results in all cases. If applied and executed properly, Project Management will reduce the risk of failure and increase the rate of success as you gain confidence and experience from project to project.

TCS/The State Group Inc.


[i] A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition, Project Management Institute, 2013.

[ii] PMP is a registered mark of the Project Management Institute, Inc.

Integrated Change Control

  • By: pcadmin on 14 Aug 2013

Understanding change control is critical for the PMP exam and your career as a project manager.

Below is a simple flowchart of a basic change control process.

Tips and tricks:

  • A change request is usually initiated by a project sponsor, client, project manager, project team member or less often by any other stakeholder.
  • Change request is the output of:
    • All Monitor & Control processes in all Knowledge areas
    • Perform Quality Assurance
    • Manage Project Team
    • Plan Procurement Management
    • Conduct Procurement Management
    • Manage Stakeholder Engagement
  • Approved change requests are inputs to Control Quality and Control Procurements and are implemented through Execute and Manage Project Work.
  • While preparing for the PMP, students are often confused about the process, some preparation guides suggest to do an impact analysis and then issue and submit a change request to the Change Control Board (CCB) while other say to issue a change request and then do impact analysis and submit to CCB. Both are correct! Change Control is a process and is usually defined in the Change Management Plan (part of Project Management Plan), depending on the project and/or organization, there will be infinite process variations on how change will be managed and controlled.
  • One thing to remember is that if a change request is issued internally (by the project manager or a team member), in most cases the impact analysis would have already been done even before issuing a change request and logging in the change log. You wouldn’t want to issue multiple change requests when a simple impact analysis will show the impact of the change will be unacceptable by the client or CCB. Once the change request is issued, the project manager will follow the same process and submit the existing impact analysis (with any updates or edits) to the CCB.
  • For change requests issued by the client, sponsor, or any stakeholder, the first step will usually be a change request is issued and recorded in the change log and followed by impact analysis and so on.
  • Approved changes can require revision to schedule and cost baselines, activity sequencing, resource requirements, and risk reassessment. Any changes to scope or product specifications should be managed through configuration control. Review the post on Configuration Management and Change Control vs Configuration Control if you are not clear on this topic. 



Configuration Control vs. Change Control

  • By: pcadmin on 09 Aug 2013

This is the fourth in a series of posts on commonly confused terms for the PMP exam.

Configuration Management’s focus, in the context of a project, is on controlling changes to the project’s product’s functional and physical specifications (also called configuration items) as well as project baselines. Review the post on Configuration Management for a more thorough discussion on the topic.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) defines:

Configuration Control is focused on the specification of both the deliverables and the processes.

Change Control is focused on identifying, documenting, and approving or rejecting changes to the project documents, deliverables, or baselines.

As the above definition states, the focus of configuration control is on the specifications of both the project’s product (deliverables) as well the process baselines (scope, cost, time, etc.). While change control is much more focused on the “process” part of that change.

Change Control, as defined in the Change Management Plan, will outline a generic process to identify, document, and process any kind of change. This is the intent of Integrated Change Control process. On the other hand, Configuration Control will ensure control of the specifications (product or the process), identifying configuration items to be controlled, evaluating the impact of a change on the whole configuration, as well as control after the change is processed through Change Control. In order words, as (Gladstone, 2008) states, “Three main aspects of configuration management are – version control, change control, and reports (audits).” Change Control is part of configuration management and is “process” focused while Configuration Control is specification focussed for controlling the whole confirmation.

Let’s look at an example (Wikipedia, 2013):

Virtual Case File (or VCF) was a software application developed by the United States Federal Bureau of Investigation (FBI) between 2000 and 2005. The project was officially abandoned in January 2005, while still in development stage and cost the federal government nearly $170 million. The primary reasons for the failure of the project were repeated changes in specifications, and repeated turnover of management, which contributed to the specification problem.

As a specific example, Sept 11 attacks highlighted the Bureau’s information sharing problems and increased pressure for the Bureau to modernize. In December 2001, the scope of VCF was changed with the goal being complete replacement of all previous applications and migration of the existing data into an Oracle database. Additionally, the project’s deadline was pushed up to December 2003.

The change to scope and specifications of the software would have been processed through a Change Control process as defined in the Change Management Plan. Configuration Control would have ensured correct impact analysis while changing the product specifications and ensuring any changes to the scope and specifications are documented and a new design baseline is established. The new project schedule would have been the result of impact analysis and taking into account the new configuration of the software.


Project Management Institute (PMI). (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (5th ed.). Newtown Square, PA: Project Management Institute.

Gladstone, Kent (2008), Virtual Configuration Management, PMI Virtual Library

Wikipedia (2013), Virtual Case File. Retrieved July, 2013 from http://en.wikipedia.org/wiki/Virtual_Case_File .

Components of Configuration Management

  • By: pcadmin on 19 Jul 2013

The four basic processes of configuration management are:

  • Configuration Management Planning (not included in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)
  • Configuration Identification
  • Configuration status accounting
  • Configuration verification and audit

Configuration management planning, like most other plans, requires planning ahead of time to provide guidance and direction on how configuration management will be accomplished throughout the project or product lifecycles. It involves establishing what configuration items need to be controlled, typically the level at which to control the configuration for both hardware and software; when to control configuration, normally once a baseline is established; how to change configuration through configuration control process; and the level of resources required for configuration management efforts.

Configuration Identification

A Guide to the Project Management Body of Knowledge (PMBOK® Guide)  definition – “Identification and selection of a configuration item to provide the basis for which the product configuration is defined and verified, products and documents are labeled, changes are managed and accountability is maintained.”

The main purpose of this process is the identification and selection of a configuration item (CI). “A configuration item (CI) is any part of the development and/or deliverable system (whether software, hardware, firmware, drawings, inventories and/or documentation) which needs to be independently identified, stored, tested, reviewed, used, changed, delivered and/or maintained.  CIs differ widely in complexity and may contain other CIs in a hierarchy.” (Kelly, 2005)

Each CI should have a unique identifier and a version number. Configuration management plan will help determine the level at which configuration items should be defined for both software and hardware components. For example, design of a new smartphone will have hardware and software as primary specifications which can further include configuration items:

Hardware – radio system, camera, casing, keyboard, etc

Software – radio system software, camera software, user interface software, etc.

Configuration status accounting

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) definition – “Information is recorded and reported as to when appropriate data about the configuration item should be provided. This information includes a listing of approved configuration identification, status of proposed changes, and implementation status of approved changes.”

This process is mainly concerned with keeping track of all configuration items, all pending changes, and all approved changes to configuration items. The status accounting process is mostly one of reporting on what progress the project team has made in completing configuration items and in incorporating approved changes into configuration items.  But, although the configuration status accounting process may seem trivial, there is one important function that it plays.  It provides a very useful metric on the quality of specific configuration items. (Mitretek, 2002)

Configuration verification and audit

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) definition – “Configuration verification and configuration audits endure the composition of a project’s configuration items is correct and that corresponding changes are registered, assed, approved, tracked and correctly implemented. This ensures the functional requirements defined in the configuration documentation have been met.”

Configuration audits is concerned with verifying consistency of configuration documentation against the product. There are two basic types of configuration audits: the Functional Configuration Audit (FCA), and the Physical Configuration Audit (PCA).  The Configuration Manager or his representative conducts a FCA to make sure that the configuration item performs as its design and specification indicate that it should perform.  A PCA is an inventory of the configuration items for the system (or any of its subsystems) and ensure that all of the items are actually in existence before the system (or subsystem) is accepted for testing or for production use. (Mitretek, 2002)


Kelly, Marion V. (1995), Configuration Management: The Changing Image. McGraw-Hill Companies, The.

Mitretek Systems, Inc. (2002, April), A Guide to Configuration Management for Intelligent Transportation Systems. Retrieved July 2013 from http://ntl.bts.gov/lib/jpodocs/repts_te/13622.html

A Project Stakeholder Story

  • By: pcadmin on 17 Jul 2013

Tata Motors designed the Nano, the cheapest car in the world, and needed a site to build their manufacturing plant. The Indian state of West Bengal, to encourage Tata to build in their state, acquired the land from numerous small-holding farmer landowners at Singur, and Tata built their plant. Then the farmers began prominently protesting against the “forced acquisition” of their land by the government. Tata first delayed the Nano launch and later decided to build the car in a different state, Gujarat, instead. They had to build a new plant and pay their many local suppliers to also move with them.

Tata was no doubt originally pleased that the farmer stakeholders were being completely handled by West Bengal state. In other words, they were assumed to be stakeholders of low interest and zero power, in the power/interest model of stakeholder analysis. But this shows that sometimes stakeholders of apparently low interest and power may change into stakeholders of enormous interest and power.


Upcoming events

Latest Tweets

Sorry, twitter is currently unavailable.