Sunday, October 30, 2016

Introduction to Kanban, Kanban System and Kanban Development



Imagine this situation: You have food items in your refrigerator. Some of them are running out. You figure out what items you need — when and in what quantity — and put sticky notes on the door of the refrigerator. Let’s call those “withdrawal cards.” As one of the items is running out, you pull off a withdrawal card and go to the nearest supermarket to replenish those items.



The supermarket manager also has a similar card system, which signals that those items are being emptied from its shelves. Let us call the cards used by the supermarket “production cards.” As the items fall below a certain limit due to withdrawals by customers like you, the store manager informs the supplier by this card. The supplier can check the production card sent, produces the quantity mentioned on the card, and has those items replenished in the supermarket.

If any other food item in your refrigerator is running out, you pull off another sticky note and follow the same process. The supermarket does the same with its production cards, and the supplier follows up.

Congratulations! With the help of signaling cards — sticky notes and production cards — you have just experienced “Kanban” and the “pull system.”

Concepts on Kanban and Kanban development are important to understand if you plan to prepare for the Project Management Institute’s Agile Certified Practitioner credential. Also, in the recently updated exam for the Project Management Professional Kanban has been introduced as one of the knowledge and skills in its exam content outline.

What is Kanban?

Kanban is a Japanese word for signal card, signboard, visible card or instruction card. Kanban signals are typically physical in nature, such as containers or cards, but they can take the form of a fax (“faxban”) or an email or even something web-based (“e-kanban). Kanban was first used by Taiichi Ohno on the factory floors of Toyota Motors. The Kanban system — so called because it uses Kanban – later became an integral part of Toyota Production System (TPS)1.

In our example, we have two signaling cards — the withdrawal card (the sticky note) and the production card. Because they act as signals for us, let’s refer to those signal cards as “withdrawal Kanban” and “production Kanban.”

Why would you and the supermarket use Kanban?

Kanban is used to reduce waste. Waste (called “Muda” in TPS) surfaces in several parts of the production process: overproduction, waiting, defects etc. However, one of the major sources of waste is overproduction, which happens when we produce more than what is needed or before it is needed. Kanban stops this waste, because the system is based on a pull system and has a just-in-time (JIT) approach.

Consider the typical “push” scheduling system. In this approach goods (inventory) will be pushed into the supermarket by the suppliers whether they can sell it or not. This leads to waste. If you’re using a push system in your home, you would stuff the refrigerator with food items (again inventory) whether you immediately need them or not. Sometimes, you may end up not even using those items, because you end up going out or leaving town or forgetting you have them.

Just in Time and the Pull System

In a pull system, unlike the push system, you (the “downstream” process) buy the items from the supermarket (the “upstream” process) based on a signal card — those sticky notes on the fridge. This we have named “withdrawal Kanban.” This approach is just in time because you’re getting the items as and when you need them and in the quantity that you need. It’s also a pull system, because you’re pulling the items from the supermarket as and when you need them. They’re not pushed to you from an upstream process.

Similarly, the supermarket (now acting as a downstream process) fills up on items given by the supplier (the upstream process) only when you and other customers have pulled the items from the supermarket’s shelves. The signal to produce is triggered by another signal card, the production card or production Kanban. The complete workflow for these steps is shown in this figure.2



This two card scheduling system is the Kanban system in its most basic form. The cards used in the system act as the signals and hence are known as Kanban cards (or simply Kanban).

A Kanban is literally attached to storage or a container and comes in the form of laminated plastic card. If the card is attached to the container and sent from a downstream center to an upstream center, then the upstream center will fill up the items in the Kanban tray (the tray to which Kanban is attached). Then it will send the tray to the downstream center. However, if an empty tray is coming without any Kanban, then the upstream center doesn’t send the filled up tray back.

The two card just-in-time/pull system with Kanban cards can be scaled to include other upstream processes, as shown below. Here again the downstream processes are pulling work items as and when needed (just in time) and the upstream processes are replenishing the items. This is also known as the “Pull-Replenish-Pull” system or “Replenish-Pull-Replenish” system.


Here we have put pull systems between processes (or work flow states) to give correct production instruction to the upstream process. Still in this system, some waste will be there — simply because certain inventory lies in the supermarket, which is inevitable. The ideal condition would be to have a continuous flow. That’s what is strived for in Kanban systems: “Flow where you can; pull where you must,” as Jeffrey Liker eloquently expressed it in his book, The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer.

The key takeaway here is that we visualize the work and work flow with the help of Kanban. Remember that a Kanban card is attached to a tray (or bin of parts) to move. Hence, primarily it is about visualization and taking action based on that.

Work in Progress

The number of Kanban cards tells the amount of items that are being worked upon — work in progress (WIP). Why? Because Kanban cards are physically attached to the Kanban tray; hence, they’re fixed in number or limited. By limiting the Kanban cards, we limit the work in progress and minimize overproduction and also minimize waste. Limiting work in progress, along with the pull system, also forces us to focus on the items needed by the customer and work only on them.

Managing the Flow

It’s possible that in the Kanban system there will be “work states,” when work items are being developed or processed, and “wait states,” when the system is idle. For example, when the Kanban tray is moving with an attached Kanban card, it’s in a work state. But when the food items are lying in the supermarket without being used by customers, they’re in a wait state.

By managing flow, we manage the work states and wait states and also find out if there are any bottlenecks in the system. This leads to continuous process improvement, called “Kaizen” in TPS.

So, here are the key characteristics of a Kanban system:

  • Just in time
  • Pull system
  • Visual management
  • Limited work in progress
  • Management of flow

Now, let’s cover how these can be applied in Kanban development for products, including software products.

Kanban Development

Kanban development mainly revolves around a visual board. This board is divided into various work flow states. These can be in a very simple form such as “to do” “doing” and “done.”. Otherwise, we can have multiple work flow states as they happen in software development: “analysis,” “design,” “development,” “testing” and “deployment.”

Also, in product development there can be many types of tasks or work items. For example, in software development they might be: new requirement, requirement change, critical issues, bugs, refactoring work, impediments, blocking issues, or documentation work. Each can be represented with various color codes or color coded spots on top of a plain card. You can also use various shapes for the cards: triangular, slanted, diamond. Each card is a Kanban card presented on the visual board. After all, visual management is one of the key aspects of Kanban development.

A sample visual board for Kanban development is shown below. I have kept it simple with one-colored sticky note (yellow) to denote one type of Kanban card depicting a particular type of work item. There are three work flow states — “TODO,” “DOING” and “DONE.”



The system shown above is pull, because the downstream process pulls the items from the upstream process and starts working. For example, items under “TODO” are pulled from the “Backlog of Items.” The work items are prioritized. This system, as we have seen before, also minimizes waste. You may say this looks very much like task boards used in other Agile development approaches. However, there’s a distinction — the WIP limits. On top of every work flow state, there’s a WIP limit, marked in the red boxes.

How do you know what the WIP limit should be? Through experimentation. The Kanban system itself doesn’t specify the limit; you have to figure out the right WIP limit for your system’s workflow states.

To manage the flow, you can add (or remove) wait states to the work flow states. Remember the quote, “Flow where you can; pull where you must”? This adds a certain amount of slack to the system, when continuous flow isn’t sustainable. In the figure below, a wait state — “Analysis” — has been added into the “TODO” workflow state to have some slack. From the “Selected” column under the “TODO” workflow state again we have flow. Of course, you can strive for continuous flow by removing unnecessary wait states.


There you have it. The basics of Kanban, the Kanban system and Kanban development. Now if you’ll excuse, I’m hungry. I need to go grab a withdrawal card.

Notes

1 The Birth of Lean: Conversations with Taiichi Ohno and other founders of TPS, written by Koichi Shimokawa and Takahiro Fujimoto.

2 Learning to See: Value stream mapping to add value and eliminate Muda, written by Mike Rother and John Shook.

This article was first published by MPUG on 19th July, 2016.


You may also like:




Saturday, October 15, 2016

Understanding Project Estimation in Agile Development



An oft repeated management quote goes like this: 
“Planning is indispensable, but plans are useless.”

Whether you like it or not, planning is essential. Without planning, there’s no horizon to look at and no way to know at what point in time deliverables will be given. However, anyone can tell you this: It rarely happens that the plan will be spot-on accurate. You don’t need a project manager to tell you that!

Planning leads to estimation of items or tasks to be executed in a project. Unfortunately, an enormous amount of time is spent in estimating — meticulously breaking down the deliverables to packages, then to tasks, finding dependencies and checking if anything at all is missed. Ironically, the name is “Estimate.” It means that these items aren’t cast in stone, and they need not be accurate. Also, as the name suggests, an estimate is not a commitment; it can change.

The Project Management Institute® (PMI), the leading standard body on project management, explains that there will be variations in estimates at different stages of a project, as shown in the diagram below. Typically, this type of “tornado diagram” is generally used in risk sensitivity analysis. However, I have taken the liberty of using it in estimation. After all, estimation itself is fraught with inherent risks.



PMI’s PMBOK Guide 5th Edition tells that a “rough order of magnitude” (ROM) estimate is applicable during the initial stages of the project. Here the range runs from -25 percent (optimistic) to 75 percent (pessimistic). For example, an estimation of 10 weeks will vary from 7.5 weeks to 17.5 weeks. As the project progresses, the range gets narrower as in Budgetary Estimate (-10 percent to 25 percent). In the later stage of the project the range becomes definitive; the variation runs from -5 percent to 10 percent. I have put the final range as zero percent when the final product is delivered. Only at that point in the project will the estimate and actual value match!

Another estimation technique considered by PMI — Program Evaluation and Review Technique or PERT — says there can be three types of estimates: pessimistic, optimistic, and most likely. To derive a final estimate, you have to take an average or weighted average.

You may well ask, if estimates aren’t concrete and significant variations arise in different stages of a project, then why estimate at all? Estimation helps in certain areas:
  • To set goals;
  • For decision making by considering trade-offs; and
  • To communicate with stakeholder, both internal and external.

So estimation is useful and needed. But why spend countless hours on it, when we know it’s likely to change? Well, granted that in fully plan-driven approaches, you need to have complete end-to-end plan and hence, a detailed estimate. But how about business areas where requirement churns are high? Doing a detailed, time-consuming estimation exercise in such cases won’t be a judicious use of time.

Therefore, I advise going for relative estimation.

Relative Estimation

Relative estimation is based on the principle of comparison. Let’s look at some examples.

You’re shopping for clothes. Do you ask for a shirt with a shoulder length of 110 cm and 55 mm, or do you simply ask for a shirt with small (S), medium (M) or large (L) measurement? You’re most likely to choose by checking the relative measurement and, of course, briefly checking whether it will fit you. That’s a relative estimate, first looking at your own shoulder size, then the shirts available and then choosing which one is most likely to fit.

When you’re having lunch in a restaurant, do you order 200 grams of rice, 100 grams of dal, 10 mg of salt and 10 mg of sugar? Quite unlikely. Rather, you seek out a small meal, a mid-sized one or a super-sized serving. Or you may ask the waiter what size a given dish is. The waiter might signal with his or her hands to help you decide which one will be right for your appetite. That’s also using relative estimation. (Thanks to Mike Cohn’s Agile Estimating and Planning for this explanation.)

You’re buying fruit at a stand. You see a variety of choices, smaller to bigger sizes, from lesser to more ripened, from fresh to not-so-fresh. Do you ask for mangoes that are 40 percent ripe or 110 grams in weight or 90 percent fresh? Unlikely. Rather you compare or you may ask the vendor a few questions and take a judgement call. Again, that’s relative estimation.

Now, let’s extend that to agile development, using another example with fruit.

Understanding Agile Estimation with “Fruit Points”

Imagine you have a special event at your home and you want to make a fruit salad. You have a big accumulation of fruit in front of you — grapes, apples, watermelons, bananas and mangoes. You want to estimate how long it will take to cut and dress them.


Let’s take a grape first and assign it one “fruit point.” Why one point and not 10? It’s just arbitrary. You can very much choose another measure — 10 points or 50 points or even 100 points. The idea here is to measure the relative time of cutting and dressing one fruit with respect to another.

While cutting, there are certain uncertainties involved, such as the sharpness of the knife, size of the fruit and cutting difficulty. Keeping those in mind, we have to find out how long it will take to cut these fruits: grapes, apples, oranges, bananas, pineapples, coconuts, pears, mangos, cucumbers and watermelons.

If dressing a grape is one fruit point, then dressing for a banana will be around three points because you have to peel the skin before you can cut it. An apple will be around five fruit points because you have to clear both ends, peel off the skin, cut it, and also remove the seeds. For a cucumber (botanically a fruit!), it will take more time than a grape, but less than an apple and will be in the range of a banana. Of course, if you have a big one and you want to peel-off its skin, you can assign five or even eight fruit points.


After completing the exercise for all the fruit items, I have assigned the following “fruit points” to cut and dress the individual fruits in the basket.


An orange is estimated at eight fruit points because it has a tougher skin compared to an apple, and it will take more time. Coming to the pineapple, it’s riskier to cut and will take a lot more time. So it earns 20 fruit points. Cutting a watermelon will be more time consuming than an orange but less than a pineapple. Hence assigned 13 fruit points. Coconut has to be broken first (you may need another tool for that), then coconut water taken out, and then the fruit content extracted and cut with knife. Hence it gets the highest points here. All these relative estimates are shown in the table above.

This simple example tells you how quickly you can relatively estimate for the cutting of the fruits. Now, let’s say that the fruit basket has multiples of most of the fruits. How long will it take to prepare them? Let’s look.

Timeboxed Iteration and Velocity

Let’s run a small test. We have five minutes and in those five minutes we need to figure out many apples we can cut and dress up for the fruit salad. This five minute test is our “iteration duration.” And this iteration is “timeboxed.” It ends in five minutes on dot with no extra time permitted.

After running through the iteration, we have found that we can cut two apples. Because each apple is five fruit points, that equals 10 fruit points in total. This becomes our “velocity.” In other words, our velocity for one iteration is 10 fruit points or simply 10 points.

Now consider that the fruit basket has 20 grapes, two apples, three oranges, two bananas, one watermelon, two pears, and one pineapple. How long will it take to get through all of that fruit? The answer is simple. We have to get the total amount of work by adding up the relative estimates of the fruits:

20 * 1 (grapes) + 2 * 5 (apples) + 3 * 8 (oranges) + 2 * 3 (bananas) + 1 * 13 (watermelon) + 2 * 8 (pears) + 1 * 20 (pineapple)

= 20 + 10 + 24 + 6 + 13 + 16 + 20

= 109 fruit points

Let’s round up to a total of 120 fruit points, to take into account extras, such as washing the knife between fruits and removing the skins to clear the cutting areas. And sometimes you may just want to relax your fingers a bit.

We know our velocity is 10 fruits points, which is of five minutes’ duration. Hence, our rough estimate to dress all the fruits in the basket will be 12 iterations.

Total = 120 fruit points

Each iteration = 10 fruit points

Total number of iterations = 120 / 10 = 12

We’ll have 12 iterations totaling 60 minutes or one hour. So, it will take one hour to prepare the fruit salad. Was not that quick to figure out?

Story Points, Iteration and Velocity in Agile Development

The fruit salad example lays out how estimation can be derived quickly. Similar concepts can be applied in agile development. In agile approaches, we have a “product backlog,” a live document containing all the requirements. Each item in this backlog is called a “product backlog item” (PBI). We can determine the effort required to complete a PBI by considering various factors such as complexity, risk and effort.

One interesting point to note here is that we don’t need a detailed product requirement specification or workflow diagrams or detailed design to estimate the effort needed for a PBI. All we need to know is how complex one PBI is compared to another item or how risky one item is compared to another item or what a combination of a few parameters will look like.

When we estimate the PBIs, we estimate the PBIs in “story points.” Like the fruit points of our example, story points also consider relative estimation — in other words, a comparative measurement. Story points are estimation of size or complexity or difficulty in a relative way. After estimation of PBI in terms of story points at the product backlog level, they’re taken up in iterations, broken down further into tasks and executed within a timebox.

You might be wondering how I arrived at the scale of 1, 3, 5, 8, 13, etc. — my “estimation scale,” — while calculating the fruit points. I’ve simply used the Fibonacci series here, whose sequence goes like this: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55… I’ve modified mine a bit to remove the illusion of precision (changing 21 to 20 and 34 to 40, for example).

Why the Fibonacci series? Because it reflects the idea that a greater amount of uncertainty exists as requirements gets larger. In plainer terms, you can say non-linear scale is used for estimation in story points. Other non-linear scales in use include t-shirt sizing (small, medium, large, extra-large and so on) and doubles or the power of two series (1, 2, 4, 8, 16 and so on).

Note that one fruit point or one story point doesn’t translate to a time value such as one minute or one hour. Also note that your estimation may vary when compared with another person’s or another team’s estimation. So remember:

  • Story points are relative estimates of size, complexity or risks;
  • Story points aren’t comparable; and
  • Estimating in story points is faster and minimizes waste.

Velocity in agile development is the sum of story points completed in an iteration. If a feature (a PBI) isn’t complete, it won’t be considered for velocity calculation. Why? In our fruit salad example, would you put a half-cut apple in the salad and present it to your guests? Definitely not. Similarly, in agile development, if the feature isn’t complete, it doesn’t add any value to our customer. Hence, we don’t consider that feature’s estimate in story points in our velocity calculation.

For velocity remember these points:

  • Velocity is the sum of story points completed in iteration;
  • If the feature isn’t complete, then it won’t count towards the velocity;
  • Velocity can change over the iterations; and
  • Velocities among different teams aren’t comparable.

These concepts are used in PMI’s specific certification on agile, the Agile Certified Practitioner (PMI-ACP), and also in PMP with respect to the scope management knowledge area. More importantly, if you’re working in agile development projects, then understanding story points, story point-based estimation, estimation scale and velocity are not only essential but foundational.

This article was first published by MPUG on 10th May, 2016.

You may also like:





Wednesday, October 12, 2016

PMP Success Story: Don't Memorize the ITTOs, Rather Focus on Concepts and Definitions



Vivek Vardhan, I remember, few days before the exam asked - “Am I prepared to sit?” I asked him a few questions and told him – “You are ready and you will clear the Exam.” And he did.  Today he is a proud and successful Project Management Professional (PMP®). Vivek gave the PMP exam on 22nd September, 2016 – late afternoon. He called me that evening, post his exam success and I could feel his happiness on cracking the exam.


Vivek was part of my class in March this year. Few weeks before his exam, he personally met me and wanted to gain more confidence for the exam. 

My timeline was constrained. But such was his desire and determination, I agreed to guide him fully. He used to meet me on holidays or off-days early morning and I’ll sit with him to clarify his doubts and questions.


I am happy that Vivek has cracked the PMP exam. Go on and read his experience, which is unique in many aspects.



*********

Why to be a PMP and How I decided?
I have been working for more than 11 years as a consultant, and now wanted to move ahead in the corporate ladder. Once I decided to take my steps forward towards project management in my carrier, I realized PMP could help me to do so. To avail PMP credentials, I started searching on internet and went for face to face weekend classroom training. 

I joined the 4-day face-to-face PMP program, where I came in contact with the coach – Satya Narayan Dash. I had done a little research on Satya to check his credentials and after reading his Blog, I had decided that it is the best place to start with my training.  

PMP Coaching Experience
The coaching experience was excellent as it provided an overview and summary of PMP study material topics and helped to co-relate with day to day working, which facilitated to memorise concepts of project management. 


The coaching also helped me to understand various Inputs, Tools and Techniques, and Outputs (ITTO)concepts. It also helped to distinguish between process falling into different knowledge areas of a process groups and reasons for them. 


Own Study
After finishing four-days of weekend training, I started my own study. I started with the PMBOK guide and then followed by Rita’s book. I prepared my notes to summarize main concepts, definitions and ITTO of each process. 

I had taken help of notes shared by Satya, which was useful to clarify my concepts, and also had taken three sets of Questions from Satya, which was also very helpful in preparing for exam. 

The most challenging part for taking PMP was striking balance in my professional and personal life. My job profile demands 10 hours in a day. Now managing work, studies and family was quite challenging, as I had to sacrifice on my family time and family priorities because couldn’t take the risk of messing up with the job. There were umpteen occasions that I had to ignore family because of tight schedule of work and studies. I have also spent many sleepless nights in the process.

PMP Exam Experience
Once I started scoring 60% in the sample question sets, I scheduled exam with grace period of two weeks (with target to achieve desired level of 80% with-in two-week period) at Bangalore centre. I got the date of exam on Thursday afternoon slot, which was good as I was able to sleep properly last night. It gave time to revisit my notes before appearing for exam.

As one exam strategy, I had decided to complete all 200 questions before any schedule break, also read through each question very carefully so that no need of marking to revisit again, this helped me to give more time for tricky and situational questions. 

Around 20 questions based on mathematical topics, but these were easy to answer, not found difficult as such. Satya’s provided multiple slides and videos on Earned Value Management (EVM) and these helped me to clarify concepts well on EVM. 

Suggestions for PMP Aspirants
Do’s:
  • Understand the concepts and definitions of each process, correlate the Inputs, Tools & Techniques and Outputs (ITTOs) with practical experience.
  • Prepare your notes, and read the PMBOK® guide at least twice. This is your main book, and you can choose a reference book depending on individual interest. I liked Rita’s reference book most, as found clarification in text format and with live examples. 
  • Practice as much as sets of questions, this will take you inside to understand exam pattern and understand how to deal with tricky questions. 
 Don’ts:
  • Don’t memorize the ITTOs, as it will create confusion. 

Conclusion
I want to pursue my career into the next level, in the role of a project manager for a high-end project. 

Brief Profile
Vivek Vardhan, currently designated as Sr. Advisory Consultant/Team Lead for an IT project, and associated with IBM India Private limited and have overall 17 years of work experience.



*********

Vivek’s PMP credential is available at PMI’s online credential registry. 


I am thankful to Vivek for sharing his experience and believe it will guide the readers of this blog who are aspiring to be PMPs. 

Sunday, October 09, 2016

PMP Protein: Top PMP Apps to Assist You

By Sindhu Sreenath, PMP




Part of studying for the PMP® exam involves recollecting structured concepts, formulae used for manual calculations, and terms that could be hard to remember if not used on a regular basis. 


While PMBOK® remains your absolute number one guide to PMP success, I found certain alternative approaches that will help you work on the PMBOK concepts and prepare for the PMP exam. 

Listed below are apps that I found useful during the course of my study. I used these apps as reference material while waiting in long queues, waiting for someone, stuck in traffic, or even while I lazed in bed.  



1. PMPro: It is one of the best Apps from a content, structure and aesthetics perspective. Here you can gain quick references to Formulae, Flash cards, Inputs-Tools and Techniques-Outputs (ITTOs) and even a Dictionary highlighting important terms that are sorted out alphabetically. While a well simulated Mini-PMP test of 50 questions timed for an hour is available, unlock the full PMP exam for US$9.99. They have around 1000 practice questions sorted according to knowledge areas.



2. PMP Exam Mentor: This is another well-organized application explaining concepts sorted via knowledge areas and process groups, and also through 40 project framework topics. You can get access to 1200 free questions based on knowledge areas and 688 Flash Cards. 



3. Pocket Prep: While the payed version of this app is much better to use, the free app also has its features. It allows you to send reminders counting down to the day of the exam, and alarms that remind you of your preset study-hours. It also has 'question of the day' reminders that help you answer and check the in depth explanation. Take tests and record your performance, the metrics to which are displayed on the dash board helping remind you of your strength and gaps in your knowledge.



4. PMP Exam Prep: This is probably the only app that allows you to gain 35 PDU's via paid Prep Course's that include Exam Slides, Offline MP3 Audio Files and Streaming videos. Apart from which you have access to 1 free quiz consisting of 100 questions. A detailed score analysis based on Time and type is also part of the free app. Check out their PMP Exam Videos app as well.



5. PMP Study Kit: This app stands out for its assorted terms and definitions which make a great reference used for revision on the move. It provides access to 360 questions based on Framework, Ethics and Knowledge Areas. The UI is very friendly however it does not have a timer feature.




 While there exist many other applications, this is a condensed list based on my personal preferences. Use the apps only to help as reference points, and the PMBOK as the ultimate guide. Best of Luck!


Written by Sindhu Sreenath

Sindhu Sreenath is an IT Professional & Product Technologist working with Intel Corporation, India as a Program Manager. She is a certified PMP from Project Management Institute (PMI). She has been applying Project and Program practices for over 4 years on managing Product Enabling teams and is now keen on developing her IT Product management skills. She has represented India in Rugby and has played Basketball and did Athletics for her state, at national level. In her spare time she enjoys Travel, Videography, Fitness and sports and is involved in several community and volunteering activities.She can be reached at Sindhu.sreenaths@gmail.com and her travel account can be accessed on Facebook or Instagram.


You may also like:


Saturday, October 08, 2016

PMP Prep: Strategic Alignment of Projects



As of January 12, 2016 the Project Management Professional (PMP)® exam has been revised. A new area of focus is business strategy and strategic alignment of projects. PMI® has conducted extensive research on the topic in recent years and the news isn’t good:

  • Poor performance results in organizations wasting an average of US$109 million for every US$1 billion spent on projects. In other words, for every $1 spent, almost 11 cents is being wasted. A February 2016 report stated that the waste has gone up-to US$122 million for every US$1 billion investment (more than 12 cents per dollar!).
  • On average only 56 percent of strategic initiatives undertaken by organizations are successful; the reverse of that sounds worse: 44 percent of strategic initiatives are failing.
  • High performing organizations (76 percent) have twice as many successful strategic initiatives compared to the low performers (38 percent).
  • High performing organizations (57 percent) are twice as likely to have strategic alignment of projects compared to the lower performing ones (28 percent).
  • 92 percent of high performers in terms of project success and 91 percent in organization success align projects in the portfolio to strategic initiatives.

High performing organizations are the ones that achieve 80 percent or more of their projects on time and within budget and meet original goals and business intent. In low performing organizations 60 percent or fewer projects are on time or within budget or meet original goals.

And why do projects fail? The single biggest reason (58 percent) is because they’re not aligned with organizational strategy! Even if a project came in on time and on budget, it might not be what the organization needed anyway. Other dominating reasons are lack of organizational agility and lack of execution.

It’s obvious that strategic alignment of projects plays a crucial role for high performing organizations — or better put, successful organizations. Also, projects that are aligned to the organization’s strategy are completed successfully more often than the projects that are misaligned.

Linking a Project to Organizational Strategy

To understand a project’s link to the organization’s strategy, you need to understand certain terms and terminologies:

Vision: Every organization has a vision, which describes its future state. Vision provides long-term direction to the organization.

Mission or Mission Statement: Vision is accompanied with a mission statement, which describes the purpose. The mission statement explains why the organization exists and tells where it intends to go.

Goal: An organization establishes goals that will move towards its vision. Goals define what an organization will achieve over a multi-year period.

Strategy: This is an approach that you take to achieve a goal. Goals tell what an organization wants to achieve, whereas strategies tell how they will be achieved. Goals of strategic nature are called strategic goals.

Objective: Objectives are measurable steps to achieve a strategy. These are quantifiable. Objectives serving the strategy are called strategic objectives.

The Strategy Execution Stack

The figure below shows a strategy execution stack that lays out the relationship among the vision, mission and strategic goals and objectives and who cares about what.



At the top of the stack the first four layers set the target for the organization. Strategic planning of the organization considers the organization’s vision and mission. It has goals, strategy and objectives to achieve the vision. Organizational strategy and objectives show up in the shaded box of the stack and serve as the hinge connecting what’s being put forth by executive management and what needs to be delivered by the project, program and portfolio folks.

Portfolios of programs, projects and operations are created to achieve strategic goals and objectives. These constitute the bottom layers of the stack. Projects and programs within a portfolio create the value production capability of an organization. Operations create value with its ongoing nature. When they’re completed, projects are mostly operationalized. All of these components uses organizational resources to execute respective work.

Let’s examine this in the context of projects. First, some definitions from PMI.

  • A portfolio is a collection of programs, projects, sub-portfolios and operations managed as a group to meet the organization’s strategic goals and objectives.
  • Programs, which are the “children” within a parent-child relationship with a portfolio, contain a related set of projects, sub-programs or program activities. They’re managed in a coordinated way to obtain benefits and control.
  • Projects, which are also children within the parent-child relationship with a program, are undertaken to create products or services or results that eventually become benefits at a program level. Projects can be part of a portfolio directly as well.

Hence, an organization’s strategic objectives are implemented by a portfolio of programs or projects. While nicely-worded strategy documents are important, it’s equally important that the projects undertaken are aligned to the organizational strategy and then properly implemented. Any strategy is only as good as the execution behind its projects.

We saw that projects are undertaken to achieve the business objectives of an organization’s strategic plan — directly or indirectly. The PMBOK® Guide also notes that projects are authorized as a result of one or more strategic considerations, such as market demand, business need or strategic opportunity, technological advance, customer request, social need, environmental considerations, and legal requirements.

The Business Side and the Execution Side

You may be wondering, how does all of this work out on the ground in real time for an organization? And what’s your role as the project manager?

Let’s look at another figure that shows end-to-end structure from business strategy to project activity.



Traditionally, the business side encompasses those portions of the strategy that extend to the level of the portfolio and sometimes even to the level of the program. However, I’ve extended it here to the project level. Why? Because for a proper alignment, projects should have a strategic plan and business needs as inputs while being chartered and authorized.

An organization’s vision and mission are translated into the strategic plan, which has strategic goals and objectives. The strategic plan of the organization is subdivided into a set of organizational initiatives. These initiatives are grouped into portfolios and create portfolios of programs, projects and operations that are to be executed in a pre-determined period.

It is the portfolio that links projects and programs to the organization’s strategic plan. Within programs and portfolios, projects are a means of achieving organizational strategy and objectives. Projects, in turn, will have deliverables and can have control accounts where the management control is exerted. A control account can have work packages with activities at the lowest level of the project. Thus, the projects with its deliverables (or results/outputs) of an organization provide the day-to-day implementation of the goals and execute the strategic objectives.

So, what do project managers have to do with it?

Many times, strategic intent and the business goals of the organization have to reach the level where the resources are executing. Also, technical resources shouldn’t only think about delivering high-end technical solutions, but consider how the project is helping the business by delivering benefits. For projects that are strategically aligned, the business benefits can be mapped to the strategic objectives. Without this mindset change, execution of strategy will continue to fail. And the responsibility falls on the shoulders of the project manager.

Bridging the Gap between Strategy and Implementation

In research sponsored by PMI, 89 percent of executives said strategy implementation is “essential” or “very important” to their organizations. Also 88 percent of executives said successful execution of projects in order to deliver strategic result is “essential” or “very important.”

However, six in 10 (61 percent) of executives also admit that there’s a continuous struggle to bridge the gap between the strategy formulation and its day-to-day implementation.

Projects, temporary by their very nature, provide the day-to-day implementation of the formulated strategies. Hence, the role and the mindset of project managers need to evolve to bridge this gap.

In its new exam PMI has placed strategic alignment of projects in focus along with strategic management as one of the knowledge and skills project managers should understand. As a professional aspiring to be a PMP, you need to know how and why projects are aligned toward strategic goals and objectives of an organization and how formulated strategies are executed by projects inside a program or a portfolio.

References:

PMI Thought Leadership Series Report. 2015. “Implementing the Project Portfolio: A Vital C-Suite Focus.” http://www.pmi.org/~/media/PDF/Publications/implement-project-portfolio-c-suite.ashx

PMI Thought Leadership Series Report. 2015. “Winning through Project Portfolio Management: The Practitioner’s Perspective.” https://www.pmi.org/~/media/PDF/Publications/win-portfolio-management-practitioner-perspective.ashx

PMI’s Pulse of the Profession. 2016. “The High Cost of Low Performance: How will you improve your business results?” http://www.pmi.org/~/media/PDF/learning/pulse-of-the-profession-2016.ashx

PMI’s Pulse of the Profession. 2014. “The High Cost of Low Performance – A Snapshot.”
http://www.pmi.org/~/media/PDF/Knowledge%20Center/Pulse-Data-Highlights.ashx


This article was first published by MPUG on 8th March, 2016.