Posts Tagged ‘scope’

Resilience Engineering #15: Cutting Edge

by Gary Monti on September 27, 2011

“Cutting Edge” is a phrase that…well…cuts both ways. It has a great deal of relevance in applying resilience engineering (RE) in project management. One way to characterize resilient situations is, “Too complex, not enough resources, and no matter what I do someone will be disappointed.”  You and the team are “out there on the edge!” There is a big plus to this work, though.

There Is a Bright Side

Pima Chodron summarizes it in a quote from “When Things Fall Apart:”

When things fall apart and we are on the verge of we know not what, the test of each of us is to stay on that brink and not concretize.

The “Bright Side” you might have been expecting was being able to work on cutting edge technologies, or enter new markets, etc. You would be correct. There’s something else though, something vital.

Life

Managing a $30 million dollar project the opportunity was present to work with a really great project engineer, Claudio. We were a team. I knew the industrial process around which the plant was designed and worked the politics and he was masterful in keeping seven engineering subcontractors in order. The work was very demanding since the process was cutting edge and had dynamic risk a la RE.

When all was done we talked once a year to revisit the project and the difficulties that were overcome. You probably know the drill. The conversation takes you back to those moments where you just weren’t quite sure how things would go yet somehow you made it happen.

Claudio’s company ended up closing his regional office. He left consulting engineering and got a job with a pump manufacturer. Getting away from the pressure of consulting felt good at first but that feeling quickly melted. He missed that pressure. He gained weight. He lamented he was losing his edge. Why? If a problem wasn’t solved by Friday it just rolled over to Monday and he still got a paycheck. The sense of immediacy was gone. No more sitting on that cutting edge aware the project could flip either way.

(Un)balanced

Chodron also talks about the need for whatever we are doing to be slightly off center. Not so much that our work topples. Rather, just enough to reinforce the need to pay attention, to be fully present. This gets back to the challenge of situations where RE can benefit. Nothing is static, the entire project is moving, there’s no sitting still. Yet, you and the team have to come up with a way to keep the situation sufficiently stable so success can occur.

Even in these challenging economic times there just might be an opportunity to thrive. Again, Chodron sums it well in, “The Places That Scare You: A Guide to Fearlessness in Difficult Times

“Rejoicing in ordinary things is not sentimental or trite. It actually takes guts. Each time we drop our complaints and allow everyday good fortune to inspire us, we enter the warrior’s world.”

This all fits with RE and complexity theory where the solution percolates up from the small things that are done everyday combining in a constructive way. It is a building up that just might take the team to a place they thought was impossible to reach. A place where they can look at each other in the midst of all the trouble and just have a beer or coffee and bask in knowing they are good.

Students from around the world list starting the project without clear requirements as their #1 problem. Last week, in a workshop addressing this issue an interesting response surfaced in about a third of the students. In a word, discomfort. Why would this happen when something that benefits the PM and team is being developed? Let’s explore.

Some background about the method will help. It teaches simultaneous development of a scope of work and determination of a possible political path providing a high probability of successful implementation of the proposed scope of work. No small feat, just ask any project manager!

Scope and Politics

Developing scope in a no-scope environment entails using a method developed by the astrophysicist Fritz Zwicky. It is called Morphological Analysis. The short version of how to use it goes something like this: using the variables associated with the project think of all possible scopes in the situation. Go through and eliminate those that have contradictory requirements, e.g., simultaneously tall and short. This will reduce the list of possible scopes dramatically.

Now, switch to game theory. List the stakeholders (players) who can impact the development of the project and its execution. By stakeholder, list the way they are playing their particular game (strategy), and the reward (payoff) they want. Generate a 3 dimensional grid, comprising player, strategy, and payoff. Now the fun begins!

Map the list of possible scopes into the strategies and payoffs.  List the scopes that have the highest probability of surviving the games being played. This typically leaves a very short list of possible scopes. Pick one and start promoting it. Keep the other scopes as possible backups should a shift in plans be needed.

Seems straightforward enough and, for many it was. So why would some attendees experience discomfort?

Fear and Honesty

In her classic book, When Things Fall Apart, Pema Chodron states:

“Fear is a natural reaction to getting closer to the truth.”

In the workshop confusion, discomfort, fear, and some anger arose. The class was paused and a chart session was used to find out what was happening. Students gave a range of responses. Here are a few:

“Looking at gamesmanship so directly pushes on me. I have to go into my unconscious incompetencies and decide what to do about the politics. This is good.”

I made a career-altering decision 8 months ago and things have been tough ever since. This class, though, is validating I made the right decision and will continue implementing it.”

“I work with a nice guy who isn’t pulling his weight. We have the same boss, whom I like, and she wants him to do better but nothing gets done. I am feeling a lot of pressure. This class is getting confusing!”

“Why this game stuff? We have technical work to get done and I just don’t see where politics applies.”

“I don’t see where any of this is relevant! Just how am I supposed to use this?”

That first respondent is very self-aware. She stayed with her discomfort and did quite well with the material. Prima fascia, she would make a good team member. The last respondent left in anger at the next break.

But the other respondents, what about them? There isn’t enough space to go into them right now. Instead, it would be better to close with a list showing a few responses people may choose in a no-scope situation. Having this list may help you profile your own situation and determine how far you could get with a given scope based on the stakeholder population, time, money, and resources present. Here are a few of the possible positions people can take:

  1. Is a natural in this situation and is on board;
  2. Has a fear of dealing with politics and reacts by actively work against the project;
  3. Can see benefit but is afraid to go to those uncomfortable spaces where politics is addressed and stalls;
  4. Is afraid but sees the benefit of pushing on themselves and working through the difficulties and is willing to push through;
  5. Only likes working in defined situations and goes blank in no-scope environments.

Maybe by keeping the above in mind and looking at your own power, authority, time, and resources you can gauge just how far to push with which scope. Ideally, you’ll do reasonably well and live to see another day and manage another project.

Project Reality Check #15: The Requirements Game

by Gary Monti on March 29, 2011

Nailing down requirements is the number one complaint of project managers. Addressing this requires two skills: political adroitness and finding a balance point between exploring solutions and exploiting what is known and available. I’d like to share some from a workshop I provide on decision-making in uncertainty.

Political Adroitness

A mantra regarding project requirements goes something like this,

“Requirements are stated needs, expectations are unstated needs. Clients tend to judge based on expectations.”

For example, a common retail experience is a customer picking a $20 pan from a display that includes $200 triple-clad pans. The expectation frequently is quality-by-association. As you might guess, the customer ends up disappointed because food cooks unevenly, burns, and sticks to the pan. They return to the store angry that misrepresentation occurred and they want their money back, at a minimum, or demand the $200 pan at no extra charge, at the extreme.

When something similar occurs on a project the best way to deal with it is by leaning into the situation as quickly as possible. The longer the expectation is held, the greater potential for damage in the relationship. Do this is by offering possible “straw” scopes. These are scopes that fit within the time and money parameters established and meant as much for example as anything else. This can take several iterations.

Initially, the goal is getting the client to see the expectations just don’t match the time, money, and resource limits established. In other words, see if they will shift their view and do it in such a way the relationship stays intact. When acceptance of the need to shift sets in, then drive towards THE scope that appears to work.

The reason “appears” is used is simple. The scope has yet to be drilled down to clear requirements that can be turned into specifications. Which leads to another aspect of political adroitness – working with the team.

The team needs to be involved in creating the scoping alternatives because they are the ones ultimately shouldering the responsibility. As you might have already guessed, having a good working relationship with team leads and subject matter experts is critical. If these relationships are absent team members can simply say the requirements aren’t clear, take a passive-aggressive position, and leave the project manager hanging.

The Explore/Exploit Balance

In complexity theory the above falls under the “explore/exploit balance.” This is where the risk comes into play. Typically, there is insufficient time to explore all options. On the flip side, the team may run into conflict and severe limitations if they dive in based on using what has worked in the past. The solution is best when the customer, project manager, and the team all share the risk. In other words a balance is needed; one that is optimal and spreads the benefits equally with the difficulties.

To recap, it isn’t enough to simply say the client should be realistic and not expect a $20 pan to perform like a $200 one. The PM and team need to push as far as they can working with the client in developing a realistic solution – one that will save reputations, relationships, and pocket books as well as produce the desired deliverable.

Project fogs are maddening. They are:

  • Pervasive;
  • Sensed by all;
  • Capable of frustrating excellent plans;
  • Have broad impact on project performance;
  • Complex and, like all things complex, require reams and reams of reports to define thoroughly making it virtually impossible to understand on paper. Nothing specific jumps out;
  • Unable to be resolved with a quick fix;

What does a project manager do? The answer is simple and can be stated in a paradox, “Embrace the project fog.” To do this the fog must first be understood.

When a project starts “things happen” and the fog begins to roll in. It shows up at boundaries taking the form of technical problems along with the environment and key stakeholders being confused, undirected, uncooperative, unsupportive or even antagonistic. The project manager is faced with the challenge of getting the project moving again while staying within the triple constraint of scope, time, and budget.

Brittle Plans

Usually, no plan is perfect. The reason is the plan is an abstract and a distillate of the planning process. It contains what the team thinks will work based on certain assumptions and is drawn from a larger universe of possible solutions.

Within project constraints the wisdom of the team is forged into the knowledge-based plan.

There can be alternatives built in but no plan is omniscient. So, things happen and the plan can become brittle and break. This is why toy makers have children play with the final product. A two year old can quickly find limits and defects in a product developed by a room full of engineers.

The Solution: Embrace the Fog

To disperse project fogs the project manager and team must embrace it. Embracing the project fog means dealing with it on its own terms. It means finding something that is equally pervasive, can be felt by all, and has a broad, positive impact across the difficult boundary. The solution has some other characteristics. It is:

  • Readily implementable;
  • Truly simple, i.e., dispels most or all of the fog by resolving all the conflicts and uncertainties;
  • Ultimately easily documented, and;
  • Seen by all as being a realistic solution;

The solution is the fog’s equal in terms of appearance and a countermanding positive performance. It is the team’s wisdom focused into a new or modified deliverable and/or process commonly called the workaround.

Yes, the word that gets beaten and abused – viewed as something just about anyone can do so, hop to it and git ‘er done. The fact is a truly good workaround that satisfies everyone from conceptual engineer to maintenance technician could be quite sophisticated and frequently a work of art.

The workaround’s simplicity can be viewed by the uninitiated as simple-minded.

I doubt anything could be further from the truth. Why? There is no linear, detailed, step-by-step path to the solution. The successful workaround reflects a power arising from and distributed across the diverse team, not resident in any one person or thing. Changing the team members or distracting them with too much work can disrupt the dynamic and turn off the ability to embrace the project fog.

So, when confronted with project fog embrace it! Pull your nose out of the details, put the team in charge, turn them loose, buy the coffee, soda, and pizza. Let them create the simple, documentable, durable solution. Watch them work their magic!

Inherent conflict between projects and operations might be called white-collar cage wrestling. Participants are focused, strong, and may carry the belief – winning means dominance of their approach. Who’s right? They both are. What is at stake is delivery of a product that performs well and is sustainable. This is especially true when the deliverable goes into production as an ongoing process or tangible deliverable produced in quantity. There is a solution to this tension, but first examination of the underlying causes will help in crafting that solution.

What Is Success?

Projects bring about change – that is why they exist. So, success is defined by bringing about some transformation.

Operations go in the other direction. Success is defined by stability. Specifically, stable reproduction of the desired process or product.

From a somewhat oversimplified perspective the situation can be restated as: Six sigma can be highly relevant in production while having little or no application in executing the project.

Is There a Middle Ground?

Can a compromise be reached? A better question might be, “Is compromise needed?” The answer is, ”No.” Taking a page from the Software Engineering Institute’s Taxonomy of Operational Risks a solution can be found. A very robust list of categories provides a framework for guiding projects in a way that leads to sound operational performance. Terms such as “usability” and “maintenance processes” are included. The definition of project success includes operational success!

So What’s the Problem?

This all seems well and good, and it is until other realities step in – the introduction of constraints. An example from the auto industry shows this well. In the 1970s the reality of “world cars” was exploding onto the scene. The desire to lower production costs plus move into international markets caused a frenzy of effort that continues to this day. This was compounded by issues commonplace today, e.g., time zone, cultures, metrics, languages, etc. The driving force at the time was the US market.  In the rush to globalize some cars in the US ended up having a mix of metric and standard parts.

Another constraint is the huge appetite for variety in the American market. Designers were pushed to develop new, fresh designs on an almost annual basis. Production and maintainability took a back seat. This led to craziness when it came to maintenance, e.g., having to loosen motor mounts and jack up the engine in order to change the oil. Some companies, such as Jaguar, almost went out of business over these issues. Boeing and Airbus could probably weigh in on this topic, too.

A Broader Solution

What shows when stepping back and looking at the situation is poor governance. The tension and animosity that can exist between project managers and operations managers may simply be a reflection of failure at the top.

Balancing the constraints is the responsibilities of senior management. It’s why there are the extra zeroes in senior management’s paycheck. This has been well stated in the career guidance book, “What Color Is Your Parachute?

To let the tension simply roll downhill to the operations and project managers can reflect poor risk and quality management if not an abrogation of responsibility.

If experiencing high tension and severe challenges then the pathway out includes looking up for direction rather than preparing for the next peer-to-peer fight.

Project Leadership #4: Trust is bidirectional

by Himanshu Jhamb on January 10, 2011

There have been many a books written about TRUST. It is, without doubt, one of the most important assessments that we, as humans, make, usually internally and act on the basis of that. In the project management world, there are a number of levels at which the PM needs to establish trust, before s/he can make anything happen. A few key ones that are encountered day to day:

  • Trust with the Client
  • Trust with your Management
  • Trust with the Team

Now, trust is a funny thing. It has a way of following the age old adage – “What goes around, usually, comes around”. In other words, it is bidirectional. The tricky part about trust is that you cannot control when and how you’ll get it, no matter how hard you try. In fact, it is one of those unique things that you get, only by giving first!

Coming back to my three categories above:

TRUST with your CLIENT

Establishing trust with the CLIENT is to provide them with stellar service that sends a clear message that you CARE for them. It is not about appeasing them, but guiding them. Amateur Project Managers might shy away from guiding the client thinking “The client is always right”, Project leaders know that clients are humans, too, and that humans have this strange knack of “Not always being right”. In this knowing, Project Leaders are compassionate to their clients’ needs and also, their ignorance (Yes, clients can be ignorant – not a bad thing, if you are compassionate to their needs). Once the clients learn to observe and value this CARE, the ground is fertile for trust to bloom. Trust can be a beautiful thing. It lowers the cost of transacting with the client(s) manifolds. Project leaders who have experienced this know what I am talking about.

TRUST with your Management

Assuming that you work for someone, there is a set of folks who are as important to your career well-being as the client. Your Management team, that is, the people that you report to. Your Management team is your primary client – You could do a fabulous job for your company’s clients but not take care of the concerns of your own company; that’s when this distinction shows up in not so pleasant ways. You need to establish trust with your management so that you keep the cost of transacting with them low, as well. Here are a few ways of doing that:

  • Reporting status to them before asked for.
  • Making sure there are no to very little escalations in your project(s).
  • Running your project on time and within budget.
  • Being a hawk with scope on your projects.

These are all ways of taking care of the concerns of your management – and hence, the building blocks of trust with them. By now, I am sure you are getting the gist of this post: These actions are all about giving first… and in turn, you are rewarded with their TRUST.

TRUST with your Team

One of the most important and commonly overlooked aspects by project managers is establishing trust within your team. Again, it all starts with a declaration of CARE for your team. Project Leaders show this in a number of ways. My favorite is to make sure that when you make commitments to the client and put a plan together to deliver those commitments, you DO NOT plan on having your team work more than the regular workday. I have seen many a project plans where the team is slated to work 12-14 hours in a day for over 2 months at a stretch. Heck! I saw one in which the PM had the team working for 36 hours in a day! It is not surprising that morale is low in an overworked and underappreciated team. Another way is to be result-focused and not overly rules-focused. Unless you are working with a bunch of monkeys (highly unlikely – though, I have heard some folks call their teams that!), you need to take care of the human concerns of people. As long as you keep your head wrapped around results, and be flexible with everything else – you will be rewarded with TRUST. I have personally been bailed out of sticky situations by my team many a times, and have even had the team putting in extra hours to get stuff done on their personal time – WITHOUT being ASKED! It’s a wonderful thing when you see this on your projects… when things follow the path of least resistance and simply flow… bidirectional, like TRUST!

Have any stories that made your life really easy as a Project Manager, once you established TRUST? Do share!

“Hangman” is a game having a lot in common with project management. The goals are identical, i.e., figure out what the stakeholder(s) in control wants/means without them telling the project manager (PM) directly. The noose of the triple constraint tightens as the PM and team try to decipher just what is needed and they miss the mark.

There IS a substantial difference between Hangman and managing a project. In Hangman determining the word or phrase (scope) the controlling player has in mind is all that is required. 500-325 dumps With a project there is a chance for triple jeopardy since the PM and team must not only get the scope correct, they must also make sure there are sufficient resources left in terms of time and money to actually implement the scope. There is a way to not only survive but also succeed in such situations.

Terminology – Constraints vs. Principles

The first thing needed is a distinction between what is desired and what actually works. The term itself, “triple constraint,” implies boundaries of some sort. There is value in taking this term apart.

Rather than say, “The triple constraint means scope, time, and budget” stakeholders would be better served by stating, “There is a scope constraint, a time constraint, and a budget constraint placed on the project.” Why? Simple. Scope, time and budget refer to three of the nine principle sets in project management with the other six being communications, human resources, procurement, quality, risk, and integration.

“Principles” means there is a balanced interplay among all the variables and stakeholders in the project. Constraint means an arbitrary limit being placed on the project. It is called arbitrary because it is made in isolation with the responsibility for integrating being passed along illegitimately to others usually down the power chain.

That sounds like a pretty strong use of “illegitimately.” However, it does apply since the responsibility for a constraint stays with the person who makes it especially if he is the power broker.

Wishes and Business Cases

A constraint, then, is essentially a wish to make something so. What works better is examining what is realistic based on the business case. That business case needs to be grounded in reality. For example, if the project is to open a low-risk savings account then having a “budget” constraint of 1-3% interest rate is reasonable. 100-101 dumps On the flip side, if I am demanding 12% return with the same low risk then I am working from a wish list. The demand will be illegitimate if a PM in charge of investing the money is punished for failing to find a secure 12% savings account. It gets even worse if the wish of having the high return investment includes being able to withdraw any time without penalty (schedule constraint).

Stated more positively:

When needs are derived from realistic business cases rather than wishes, a bridge can be built between the business case and associated project principles comprising scope, time, and budget.

Going back to the previous blog, Rainmaker, building that bridge requires incorporation of other principle sets. In the next blog we will explore those principles with the goal being generation of a balanced relationship with realistic boundaries between scope, time, and budget. It involves the creation of something far more elegant than a triple constraint.

Project Reality Check #2: Being a Rainmaker

by Gary Monti on December 28, 2010

“Rainmaker” is a title that fits with a lot of project managers. It sets the bar high requiring a great deal of skill and political savvy to bring about the deliverable as if almost by magic. The reality is quite different. In fact, there are several realities that must be juggled to be a successful rainmaker ranging from the very concrete to the intangible. This can be seen when looked at through the nine areas of project management: scope, time, budget, human resources, procurement, quality management, risk management, communications, and integration.

Nested Easter Eggs, Projects, and the Truth

Imagine a project as a nested Russian Easter egg. At the core is the candy, the measurable deliverable – the client’s main focus. Surrounding it is the smallest Easter egg – the triple constraint. The painting on this egg is an orthogonal latticework of scope, time, and budget with one axis just a little wavy. Time and money can be measured, as can portions of the scope. The scope, however, starts bringing in the intangible because it is driven by client needs, each one of which can be multilayered itself. This is why the one axis is a little wavy.

The language of the triple constraint reflects the deliverable but is different since it includes the time and money aspect. It also is more complicated because there are three dialects; one each for scope, time, and budget.  The language gets more complicated because there is a change in the truth system being used. That is how different languages develop, i.e., attempts to describe different realities.

In other words, when we talk “deliverable” one language is used which is different from when we talk “scope, time, and budget.” For example, imagine a soccer player who can put an amazing curve on a kick. Talking about the beauty of the kick is one thing. Talking about everything that went into that player to get to the point where the kick could be made is another. (Many a beer or other beverage has been drunk enjoying going back and forth between these two languages. It’s all very human and very much a part of any project.)

The next egg (layer) has a supply chain network drawn upon it. It comprises procurement and human resources. People, equipment, facilities, etc., are needed so the project can be completed. The intangibility increases. There are more, varied conversations occurring all of which need orchestrated and harmonized. The discussion around this orchestration and harmonization creates another language with two dialects.

This brings us to the next larger egg, which has a swirling pattern of two distinct colors representing quality- and risk management. Imagine it being drawn by a pointillist. Each dot represents a specific test of a component or system (quality) or a specific threat or opportunity (risk) that must be addressed. Holding the egg at a distance the swirls can be seen representing the interaction between quality and risk and how together they influence the inner components of project management and the creation of an acceptable deliverable. And, you may have guessed it, yet another language with two dialects is created.

And what about the conversation itself? This is where communications comes into play. This egg has a nervous system painted on it. Actually it is more like an LCD display where the flow of information through the nerves can be seen. This flow represents the even greater level of intangibility. Why? The message is in the flow between the various parts of the project.

Finally, the largest most intangible egg of them all – project integration. It is invisible. This egg can be felt but can’t be seen. Imagine a magnetic bottle. There is a very real force field present containing the other eight areas of the project along with the specific project components, stakeholders, and the energy that flows between them. This egg can be experienced, it can be discussed, it can be influenced but it remains invisible. Its language is one of connection and interdependence.  It reflects the achievement of acceptable balance among all stakeholders, components, and their performance. The integration exists in that balance rather than inside any one thing or person.

The deliverable only comes alive and is acceptable when integration has occurred and is sustainable.

What does this mean? An intuitive example of connection and interdependence is the relationship between an aircraft wing, the engine, and the payload. The engine must generate sufficient thrust to propel the wing forward and generate lift. However, if a large enough engine is too heavy then the design is pointless because there is insufficient lift left for the payload.

What makes a project manager a rainmaker is the ability to achieve that integration. It is reflected in commitments within the stakeholder community. Those commitments are then mapped into the design and creation of the deliverable through the project plan and execution of the schedule. Oh, did I mention there might be some magic involved?

Project Reality Check #1: The Challenge!

by Gary Monti on December 21, 2010

“Challenging” summarizes project management well. This series of blogs will go into the day-to-day realities of project management as well as the theory and bring to light ways to deal with the challenges.

As the series progresses validation for what you already see and do will occur. So, why write this material if that is the case? The answer is simple: Validation is powerful. Projects require connectivity, which requires being seen and accepted – Validation.  Additionally, there will be a few new things that will prove to be valuable.

There’s Just One Project

Listening to students and/or clients from every continent except Antarctica (would like to go there someday) there is a common theme in the answers to the question, “What makes your projects so challenging?” It breaks down to the following:

  • Lack of clear requirements;
  • Being pushed to start, regardless;
  • Arbitrary end date;
  • Arbitrary budget;
  • Dictated resource pool comprising too few resources of adequate skill;
  • Multitasking.

The response is amazingly consistent and is independent of profession, field of study, market, etc. It has led to telling clients and students, “There is just one project in life and we all get a turn on it.” Human nature is the same everywhere. All that differs is the wrapper (culture). Don’t get me wrong, that wrapper can be quite significant. My point is once the effort is made to get beneath it you’ll always find the same thing, A human being.

The Path

This all can sound pretty bleak and make one wonder, “How does a project manager get the job done?” The answer is simple, “Stick to the principles.” As has been stated in previous blogs, simple is not the same as easy.  That simple path is grounded in the 9 areas of project management. By sticking to those principles and flexing them as called for in a given situation the odds of finding a path to success go up accordingly.

The Areas of Project Management

According to PMI® there are 9 areas of project management:

  • Scope
  • Time
  • Budget
  • Communications
  • Human Resources
  • Procurement
  • Quality
  • Risk
  • Integration

We will explore these 9 areas and see how they relate when working to find that path to success when thrown into a challenging situation.

A Key to Success

The word “challenging” opened this blog. To some extent, it is politically correct. “Nightmarish” might be a better word, when you get down to it. How to enjoy situations, stay sane and avoid project nightmares has been a quest ever since entering project management. The secret, which will be explored in this series, is completing a simple sentence.

If everything were okay I would see ________________.

It took most of the last 32 years spent in project management to get to that inquiry (proof that simple is different than easy).

A few things stand out with that statement:

  • It is an inquiry rather than a command. Why is that important? Leaders do better when asking more questions and giving fewer commands;
  • It is recursive. That one inquiry can be asked over-and-over as the breadth and depth of a project are explored.
  • It applies to both politics and technology. The stakeholder map should map isomorphically (clearly) and correctly into the technological map of the project.
  • Variance analysis is promoted. Using that statement promotes gap analysis, which is at the core of project management.

Variance brings us to the goal of project management, i.e., making sure we know what to plan, plan it, and execute within the time, money and resource constraints that fit with the project. In other words, get the job done. It gets down to two simple equations:

Cost Variance = Earned Value – Actual Cost

Schedule Variance = Earned Value – Planned Value

This series will explore what it takes to put teeth into those two equations. Fasten your seat belt!

A little more about Projects

by Himanshu Jhamb on December 7, 2009

ProjectA while ago, I had written about “What a Project is Not”? This post is an extension of that post in which I will discuss why projects are needed and what projects, in fact, are. You will probably get as many interpretations of what a project is, as the number of people you talk with and most of them, are probably right in their own way. But, we are not talking about right or wrong here; we are concerned about what makes for a more powerful interpretation and that’s that. This obviously leads us to the question:  What makes something powerful? The answer is really simple – Anything that is in alignment with why it was invented in the first place makes up for a powerful way of existence. In Projects speak, this would be the purpose of the Project.

So, Why are Projects needed?

Projects are needed when old practices and ways of doing things no longer generate effective results or worse, generate breakdowns that we have to cope with. One of the most common sources that generate the need for projects is the rapidly changing marketplace. Today’s marketplace (as opposed to the one that existed 30-40 years ago) calls for the invention of new projects at breakneck speed. All you have to do is nothing for a month (probably, not even that) and you’ll see how your competition edges you out to obscurity.

What do you need to Invent a Project

The most fundamental thing that is needed even before a Project can be invented is – You must be “Up to” something. It can be as simple as going from point A to point B OR as complex as going to the moon. What you are “Up to” defines why you are inventing the project.  Entrepreneurs are inventing projects all the time. Projects teams are enrolled in this “Project mission” and “execute” on a “plan” towards achieving this goal.

How are projects brought into existence?

Projects are brought into existence by making specific declarations of what it is that will be produced at the end. There are, of course, other parameters on which specific declarations are made around – scope, time line and resources, to name a few but, at a fundamental level these are all declarations of producing a specific result by a certain time frame.

Projects are Costly, yet Unavoidable and Necessary

This is perhaps, the only guarantee, a project carries. Yes, it’s unfortunate, but true. Projects are inherently costly (we obviously see this as an investment – that’s why we incur the cost, but I’ll continue using the word “Costly” for now)  and what makes them so is that it takes time, energy, money and lost opportunities to learn the new practices & tools that are needed to run the project, efficiently. Then there are the costs associated with resources and then there are the many unknown costs – that only show up during the execution of the projects.

It would be a disservice to the topic of projects if I ended on the rather somber “Projects are Costly” note… Projects are also unavoidable and necessary … in that, they will continue to exist and invented as long as the marketplace continues changing and businesses find themselves coping with the changing landscape. Projects have an immense capacity to produce exceptional results to take care of the concerns they are invented for – as long as they are planned for, managed and executed well.

<Shameless Plug Begin>

At Active Garage, we keep tinkering on projects. We have two projects (one completed and one still going on) and more to come. Please check out our current projects here:

1. defiant, a social media powered eBook

2. BLOGTASTIC series

</Shameless Plug End>