Project Mission Statements

It’s often easy for people to focus on differences. Skinny and round. Tall and short. Political party or no party. It can be easy to fall into the trap of observing the divide between any two things.

A good project manager is an excellent study of human nature. They know how to guide their stakeholders to success around obstacles like these and build the bridges and networks that will allow all the people involved to be successful. One way to keep everyone on the same page is to create a project mission statement.
Mission statements are helpful because they document a shared set of values and a shared goal for both the development team and the client. This allows each team member (regardless of team) to make decisions to move the project forward.
Good mission statements are written to answer the who, what, when, how, and why of a project. Early client agreement to a mission statement is key and references back to the mission statement during client presentations is expected.
One example of a mission statement is: “On an ongoing basis, the Project Team will use best practices to maintain, design, and develop application features to sustain and increase utility, user satisfaction, and scalability of XXX CLIENT.”

I usually team PM’s to draft up the mission statement early in assuming the project and refer to the client for final approval of its wording. Once its wording is agreed upon all the stakeholders involved in the project can refer back to the mission statement anytime they’re faced with something ambiguous. This saves the PM from a deluge of phone calls as the project evolves.

In one project our lead engineer was working abnormal hours to sync with the company’s world wide development team. The PM was asleep. When questions would come up from either the lead or the remote developers they were able to refer to the mission statement and press forward. They didn’t lose a single hour of productivity in the project. Similarly, the PM was able to guide the team using the mission statement and reduce the number of ad-hoc client meetings.

A missions statement sounds like a simple thing, but it can build bridges and give focus to the wide variety of stakeholders involved in the project. That focus directly translates to project momentum and success.

Build your project’s momentum. Write a mission statement.

The Triple Constraint In Waterfall & Agile

This post was originally created as an internal tool for the staff at Ventive. It is used here with permission.

The Triple Constraint

There are three axis’ of any project that are naturally bound to one another regardless of project management technique.  These three axis’ are the project’s scope (the list of requirements to be accomplished), schedule (the time frame to finish the project), and budget (the available funds to complete the project).   An increase to the project’s scope can’t be done without proportional increases in the project’s timeline and budget.  Similarly, a client who reduces their requir

ements will enable the reduction of the project’s spending and the project’s schedule.  The same interconnection holds no matter which area is first impacted.  A client may have greater sensitivities to time (I want it faster) or funds (it needs to cost less) than scope.

These three axis’ are known in the PM literature as the triple constraint or the iron triangle.  Communicating internally and externally using the triple constraint is a standard technique for a project manager.  In general clients may not be aware that they exist or how they interact.  If the client is unaware of these constraints, it is the PM’s responsibility to teach this reality to the client and continuously refer to this throughout the project’s life cycle.


PM Techniques:

The two most popular project management techniques are Waterfall and Agile.  Each technique has strengths and weaknesses and rather loud proponents on each side of the discussion.  Ventive uses a hybrid approach to Project Management that has both agile and predictive components.  This hybrid approach has roots in Interative and Incremental Development (IID), which dates back to NASA’s Mercury program.  Our hybrid approach allows us to efficiently deliver quality to our clients while creating an environment that improves the stakeholder experience.

Many of our clients are familiar with some of the terminology in Waterfall and some of the terminology in Agile and its important for you to understand these terms and their functions.


Waterfall is the most prominent technique in project management in practice and in the literature.  The technique is built off the premise that all of a project’s requirements are known at the beginning of a project.  In addition, all of the work necessary to create the deliverable must be known.  Not only does this work have to be known, but the way that each task and each resource interacts with one another also must be known.  This creates a huge requirement for the discovery phase of a project.  Not only would a Project Manager (PM) need to know all of the requirements, but they must also know how all of those requirements interact with one another.  

We know the least amount about our projects at their beginning.


Another limitation of the waterfall process is the methods for client interaction.  In waterfall the client is involved in the initial phase of determining requirements, but is then removed from the process until the final verification.  If a client misses identifying a requirement early on that requirement can still get integrated, but the changes are managed through a process that is often built to be difficult and more costly for the customer.  Between the exclusion of client input and the cost associated with their delayed input, Waterfall can be an expensive and frustrating process for a client.

Waterfall is best used in projects with high certainty and low complexity.  Construction projects still rely heavily on Waterfall regardless of their complexity which often explains why many projects will deliver behind schedule and over budget.  Several tools have been developed to reduce the uncertainties associated with this model of development.  Some of the techniques and tools for project management developed for waterfall have applications in Agile and IID.

Tools such as Work Breakdown Structure (WBS), Gantt Charts, Pert Diagrams, Critical Path, and Critical Chain are predominantly found in waterfall project management.  Some clients will have familiarity with these topics.  It’s not uncommon for a client to request products associated with these topics during the project’s life cycle.  Many of these products give a false sense of understanding a project’s progress.  While they are often highly detailed products, they are just as often wrong.


Waterfall projects start with a description of a project’s scope and then go through a phase to discover the acceptable budget and schedule in order to deliver that scope.  This effort requires inquiries along two different axis.  This means there are more unknowns than knowns in the project.  Typically the PM works with the client along the axis towards schedule and cost.  While all three are interrelated there is no set formula.  By pursuing two directions at the same time the team (PM & client) will inherently miss things.  In destructive settings the PM and client will both blame one another for missing important information along these axis.  The reality is that the people aren’t to blame, the procedure has inherent flaws.  

Waterfall does not always lead to destructive conflict.  It only results in destructive conflict if both parties fail to recognize the limitations of the method.  If these limitations are acknowledged early on and mitigated waterfall can provide a fast, predictable, and positive experience for the client and the PM.


Agile is arguably the second most popular technique for project management, however instead of focusing on projects it actually focuses on products.  And instead of it being a technique it’s actually a series of principles.  Confusing?  Because it’s thought of as a specific project management technique and it’s not a great deal of those who’ve heard of agile have difficulty understanding what it is and what it isn’t.

Agile’s story in part begins back in February of 2001 when seventeen people gathered in Snowbird Utah to try and develop a consensus based upon their successes in software development techniques.  The consensus over techniques were never reached.  Instead they shared techniques and realized that they shared 12 principles.  The 12 principles of agile are:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Several methodologies have emerged to support these twelve principles and provide a framework to development teams.  Agile has become an umbrella for several disciplines of product development.  Two of these most popular methods are Scrum and Extreme Programming.  image1

Scrum’s framework contains rigid rules for roles and responsibilities designed to maximize the productive output of each person in the process.  The rules for other techniques are similar, but less rigid in the other techniques.Several methodologies have emerged to support these twelve principles and provide a framework to development teams.  Agile has become an umbrella for several disciplines of product development.  Two of these most popular methods are Scrum and Extreme Programming.  

Scrum captures the product requirements and stores these in a backlog.  During sprint planning the backlog is sized for complexity and business value (priority).  The product owner (client) and the development team determine which backlog items get added to the sprint.  Sprints are specific time frames of development (usually 2-4 weeks).  Each day during the sprint the team conducts a daily scrum meeting.  At the end of the sprint the team reviews their progress, shows the client the working product, and reviews what went well or what they need to improve on for the next sprint.  Then the cycle repeats.

Scrum clearly includes more customer interaction than waterfall, but doesn’t create the cohesive narrative that waterfall offers the client.  The logical process takes faith to see through the staccato development process.

Agile’s impact on a project’s scope, schedule, and budget are significant.  They essentially flip the triangle on its head.  Because the agile team is set from the beginning at a predictable rate the project’s cost becomes fixed per cycle.  The schedule is also predetermined and fixed at the start since the client and the development team agree to the length of time of each development cycle.

image7In this technique the client has to be comfortable with an unpredictable scope evolving to meet their needs over time while structuring fixed payments each cycle regardless of progress.  Despite Agile’s proven track record of effectiveness over several decades, the technique is still uncomfortable to many clients as it shifts the burden of uncertainty to the client.

Hybrid Approaches

image10The hybrid approaches fall somewhere on the spectrum of predictive (waterfall) and agile.  The two options to use when referring to these hybrid models are to give top billing to the primary technique.  It’s common to hear PMs refer to their techniques as Agile with Predictive components or Predictive with Agile components.  These hybrid labels allow the client and PM to speak a common language with a great deal of flexibility in between.

While there is a spectrum of projects that are best done using purely agile techniques not every client can adjust to a completely agile project environment.  The hybrid approach allows the inclusion of the most effective techniques for the situation and the company’s culture.  Each PM needs to be able to pull in the correct processes for Predictive and Agile management to facilitate the client’s needs.

One way to view these systems are to recognize what each brings.  Agile project management explores avenues of value with the client.  Predictive models are prescriptive in nature and generally fixed.  Let’s say Aesir Industries contracts us to develop a website to manage a financial database including customer and account information.  Prior to going live the software must go through a technical audit.  In this case the software will likely be developed using agile components where the client is reviewing the backlog and updating the course of the project over time.  The remaining work with the audit will be fixed and follow a specific predictable formula.  This means the project will transition from an agile framework to a predictive one.  Overall the project will be agile with predictive components.

The Project Quality Conundrum

In the early 1980’s the video games were seeing their first round of widespread acceptance.  The growth of a technology with such rich visual feedback had captured the attention of a wide range of investors and analysts.  It also caught the attention of visionary producers in other mediums among them Steven Spielberg and George Lucas.  In 1981 the pair released Indiana Jones and the Raiders of the Lost Ark.  The movie grossed over $389 million at the box office.  Lucas had set an example in the industry with regards to marketing that did not go unnoticed by other producers.  As Raiders was clearly establishing itself as a hit with audiences Atari was finalizing the rights to adapt the film’s story to a video game for it’s 2600 series console.  The assignment was handed off to Howard Scott Warshaw.

Warshaw’s titles up to that point included the highly popular Yar’s Revenge where the player operates as a bug that has to shoot through a barrier to destroy an enemy creature.  The graphics are simplistic by today’s standard but both the graphics and gameplay are now considered a classic of the genre.  The title’s popularity put Warshaw in good enough graces that when a programmer had to be assigned to Indiana Jones he was selected for the task.  When Raiders was complete it was presented to Spielberg who repliedepi “It’s just like a movie. I feel like I just watched a movie.”  

Spielberg was impressed.  

A marketing norm was beginning to be established.  From now on movies (and at least Spielberg movies) would be accompanied by a video game release.  Spielberg’s next film was E.T. and executives wanted to capitalize on its popularity for the 1982 Christmas shopping season, but negotiations for the licensing of development to Atari ran longer than expected.  By the end of July the legal framework was in place, but there was no game, no code, and no design.  Impressed with the complete but as yet unreleased Raiders game, Spielberg requested Warshaw take on the task of game design.  Warshaw accepted.

799px-atari2600aThere of problems with this project.  The largest among them was that in order to get the game code loaded onto the hard cartridges for the Atari 2600 console the code would have to be complete by 1 September 1982.  This gave Warshaw only five weeks to write and test the code.

In project management one of the early steps involves identifying the requirements of the project deliverable.  This requirements form the checklist to be completed.  According to our earlier definition, if the checklist is complete then the project has achieved its necessary quality.  Warshaw did everything on the checklist.  He designed and programmed a game that resembled the characters of the movie.  It had a plot that resembled the basic struggle of the film; help E.T. build a communication device so he can phone home.  The concepts were novel, the execution of those concepts made for poor gameplay.  Warshaw had completely fulfilled all the requirements with Spielberg calling him a “certified genius” in the process.  Spielberg was right.  What Howard Warshaw pulled off was absolutely remarkable and he deserves to be credited with the  praise reserved for champions.   Unlike the movie though, the game was a flop.

The term epic fail has been traced to video game inspirations, but not this one.  Zak Penn, who grew up with an Atari 2600 during this time period remarked his surprise that somehow after 1983 the Atari system, that was king of the industry, all but disappeared.  In 2014 he would tell his story and complete a quest to explain what was known as the Video Game Crash of 1983.  E.T. the game received a lot of the blame for the crash.  The New York Times summed up the sentiment about the game with a quote from an unidentified ten year old, “it wasn’t fun.”  The game sold a few copies, but far below the predicted expectation.  If ten year olds weren’t buying it, then who was?  Atari themselves answered that question, grandmothers.

Why were grandmother’s buying something typically associated with a much younger and much more male audience?  The answer to that question ties directly into the real meaning of quality.

In his book, The Design of Everyday Things, Don Norman gives a brief history of Aristotle’s understanding of physics contrasting the Greek’s perspective with Newton’s.  One of Aristotle’s arguments was that “continuation of motion depends on continued action of a force.”  From an observational standpoint this makes perfectly good sense.  Push a box and it moves until you stop pushing the box, but it flies in the face of Newton’s first law: objects in motion stay in motion until moved upon by an outside force.  Aristotle’s explanation for this part of the physical world remained the dominant theory for nearly 2,000 years of human history.  It would not have survived past his lifetime had it not been contributing to some part of humanity, but Newton’s laws clearly contributed more as they increased the accuracy and application of physical concepts.  Few of our modern conveniences would exist were it not for the adoption of Newton’s law’s over Aristotle’s.

Each one of these great men created ideas that were perceived to have value to those that consumed them.  This is our definition of quality.  

Quality is “the level to which the stakeholders value the product or service produced.”

The quality of Aristotle’s work was perceived to have value by those who consumed it.  Newton’s laws were also perceived to have value and such a higher state of value that few schools today teach the heritage of physics as a discipline and skip right to Newton’s contribution.  If it’s true that the apple hitting his head truly inspired Newton, then it wasn’t just a natural occurrence.  It was the start of a revolution of ideas that changed the world.

800px-atari_e-t-_dig-_alamogordo2c_new_mexico_281403609779229In our E.T. example we saw the completion of the project, in conjunction with the epic fail of the project’s output and the epic fail of an $3.2 billion industry.  Understanding the failure is as simple as understanding the difference in perceived value by the stakeholders.  Kids weren’t buying the game, or they were buying it and returning it because it wasn’t fun to play.  The value perceived by the kids was in the gameplay.  The value perceived by the grandmothers was in providing a gift for their grandkids that contained all the marketing material of a movie extremely popular with children.

A project’s checklist should translate to stakeholder perceived value.  After all, the checklist is likely the very list of requirements the stakeholder requested, but we can see from Atari that this doesn’t always match up.  There are other dimensions at work in the process of creating value.  When a PM begins the project it’s important to clearly define his or her scope of authority.  Do they have the ability to conduct the project to improve quality for the customer or just deliver on the checklist?  

That’s the sort of question that lives as a double edged sword, but it’s a sword that can’t be avoided.  Talking about change and value earlier on make a big difference in project quality and the quality of the process for delivery.  As a PM your name is directly associated with the success of the project.  It’s a good idea to take charge of your legacy.

The Lie of Earned Value Performance in Project Management

The four measures that serve as the basis for all earned value performance assessments and forecasts are Budget at Completion (BAC), Planned Value (PV), Earned Value (EV), and Actual Cost (AC).  Definitions for each of these terms can be found in the PMBOK.  My summary of each is as follows:

Budget at Completion:  This is everything that is projected to be spent in order to get the project done.  It is the upper limit for every project chart (unless you’re over budget and that sucks).

Planned Value:  This is the projected value of the project (based upon expenses) according to the baseline set forth by the project.  In short, it’s looking at the calendar for how much you should have spent by this point.

Earned Value:  This is the number of what the project’s spent based upon the work that’s done.  The way I remember this is that the name Earned Value derives from PMI’s idea that value is determined by the checklist, and this method calculates the amount of the checklist that’s completed in terms of dollars.

Actual Cost:  This is the number of what’s actually been spent in order to have the project proceed this far.  It’s the product of looking at the project’s actual expenses at the time of the analysis.

These metrics are used by project managers in waterfall systems to lie to their management and encourage a culture of micromanagement (especially if the project is behind schedule).  The real world examples of this facilitating a destructive cycle abound in the literature.  I’ll use the example that PMI published on Boeing’s 787 (references below).

These traditional tools can be helpful in answering questions about the status of a project.  That’s why they’re in the PMBOK, but the leadership this information is presented to must be taught what it means.  Eric Ries calls these calculations Vanity Metrics and they have no real value other than making an organization feel good or feel bad about its current circumstances.  Other than that they really don’t serve a purpose.  

Does an incomplete iPhone have any actual value?  Does an incomplete airliner have any actual value?  No.  They don’t.  So why do we calculate earned value?  There is no value from the project until the product is complete.  I really wish that PMI would re-name the EV term to IV.  It’s an invested value nothing has been earned yet.  I’d strongly recommend that a PM calculate this information for their own internal use (it’s nice to see the chart as it looks pretty), but beware of ever sharing it.  This chart has been known to facilitate the ugly beast of micromanagement in many organizations.  PMI should really put a warning in this chapter.


Shenhar, A.J., V. Holzmann, B. Melamed, and Y. Zhao. (2016). The challenge of innovation in highly complex projects: What can we learn from Boeing’s Dreamliner experience? Project Management Journal 47(2), p. 62-78.

Vega, G. (n.d.). Leadership implications in complex projects: The Boeing Dreamliner and Jim McNerney. Retrieved from PMI website: ou=225860&type=coursefile&fileId=Leadership+implications+in+complex+projects+-+a+case+study+in+leadership+and+communications+management.pdf

Beyond Broadcasting

We often perceive communication in its broadcast format.  While not inaccurate the narrow focus of this definition creates severe limitations on the human capacity to effectively communicate.  In their book (Adler & Proctor, 2007) the authors present a model for communication that includes internal noise, external noise, and the information of both the sender and receiver.  While not directly addressing the concepts of noise reduction from this model Julian Treasure took the stage in 2011 to present a Ted Talk on listening better that has implications for project managers.  

According to the PMBOK, “project managers spend most of their time communicating with team members and other project stakeholders.”  This statement translates to a minimum of 51% of a project manager’s time being spent in the act of communicating.  This also means that if someone were to create a Pareto Analysis based upon the actions of a project manager’s use of time one of the top items to address would certainly involve communication.  This also means that any action that has an impact on improving the effectiveness of communication has a significant impact on the PM’s time and the overall project.

Incorporating conscious listening techniques advocated for by Julian Treasure include the technique of Receiving, Appreciating, Summarizing, and Asking (RASA) in the context of communicating with others (Treasure, 2011).  This listening technique can significantly enhance a PM’s ability to manage team meetings.  The non-threatening nature of this technique helps to create an environment of trust that will enable others in the meeting to bring forward ideas that can significantly increase the efficiency and effectiveness of the project.  They will certainly reduce the amount of questions which occur after a meeting due to miscommunication and reduce some of the inefficiencies inherent in general communication.

The RASA process can also be beneficial when dealing with group conflict.  Wilmot & Hocker advocated for applying a collaborative conflict management strategy (Wilmot & Hocker, 2007) and RASA falls right in line with creating this environment.  Recognizing early stages of conflict is often difficult.  I have met and worked with some professionals who didn’t recognize conflict until it was explosive.  Others operated as though conflict was always occurring.  These latter professionals believed that every conversation revolved around some conflict and so they encouraged a collaborative environment to prevent destructive conflict.  I subscribe to the theory that conflict is natural and always occurring and therefore the concept of preventing conflict is quite an anathema.  Regardless, conscious listening techniques of RASA create the space for productive conflict.

While we often think of communication in its broadcast form, communication very much involves the process of listening.  As he concluded his Ted Talk, one of the things Julian was impassioned about what informing his audience to Live to Listen.  Modern PMs need to understand how listening early and often is communication, and can save them from quite a bit of broadcasting their thoughts in the future.




Adler, R. B., & Proctor, R. F. (2007). Looking out/looking in. Australia: Thomson/Wadsworth.

Project Management Institute (PMI). (2013).  A guide to the project management body of knowledge (PMBOK guide). Newtown Square, Pennsylvania.

Treasure, J. (2011, July). Julian Treasure: 5 ways to listen better | TED Talk Subtitles and Transcript | TED. Retrieved from

Wilmot, W. W., & Hocker, J. L. (2007). Interpersonal conflict. Boston: McGraw-Hill.

Cultural Differences & Virtual Teams

Accommodating cultural differences in virtual teams can feel a bit like walking a tightrope.  Having faced this problem more than once I’d like to offer the following for your consideration.

The definition of cultural intelligence is “the ability to display intercultural competence within a given group through adaptability and knowledge.  Studying the components of culture, the theories pertaining to cultural dimensions and competencies, and the current initiatives in promoting these concepts are all powerful resources for managers involved in foreign assignments” (Saylor Academy, n.d.)  Faced with the situation of multiple team members of different cultural backgrounds and scattered across the earth the first thing I would do is start gathering information on the team members.  Culture is a generalization and can be useful in developing expectations, but it is not a single reference for some of the decisions that will affect the team.  I’d likely begin by creating a questionnaire to send to the group members that could be studied and shared among the group so we can get to know one another.  These mini-biographies would help me understand the actual diversity within the group.  I would compare the information received from their responses and re-read chapters 4-9 of Adler’s International Dimensions of Organizational Behavior.  Among the questions I would ask would be the following:

  • Describe a project you worked on as part of a team and how you contributed?

    • This question provides a history to their perspectives on teamwork as well as their historical roles in contributing to a team.  This will provide the context needed to set boundaries on expectations among group members.

  • Describe a mentor in your life and one of the lessons they taught you?

    • This question can provide insight as to the character of the individual through the selection of the lesson they share as well as how they prefer to be taught.

Any communication at the outset chart the course to any of the five options identified by Adler (right) (Adler, 2007). Based upon the urgency of the project moving forward synergy will be required in order to ensure the project moves forward efficiently and can achieve its goals on schedule.

When it’s time to move the conversation towards the project then I would do so leveraging the storytelling aspects of each culture to create our own project story (Saylor Academy, n.d.).  While the questions above may be useful for identifying individual traits the real meat will come from leverage a common storytelling technique.  Burke’s redemption theory (Samra, n.d.) is great among western cultures, but doesn’t necessarily work as a model across other cultures.  There are a few different ways to analyze the stories of other cultures.  The most thorough would be to consume content from those cultures, the other would be to identify the themes that resonate from a single story as perceived by members of other cultures.  Due to time choosing the later would be the most efficient, and the artifact of choice would need to be respected and consumed by all the cultures to serve as a denominator.  I’d probably use Star Wars as this artifact and then build upon themes across all cultures to help create our project’s story.


Adler, N. J., & Gundersen, A. (2007). International dimensions of organizational behavior. Princeton, NJ: Recording for the Blind & Dyslexic.

Samra, R. J. (n.d.). SAMRA. Retrieved from

Saylor Academy. (n.d.). Working with People on Projects. Retrieved from

CYCOPEDE: Universal Quality Assurance Definition

It may not be universally accepted, but ISO 9000 does a pretty good job defining and explaining quality. The definition it uses is, “the degree to which a set of inherent characteristics fulfills a need or expectation that is stated, general implied or obligatory” (ISO, 2009). The author explains this definition using Maslow’s Hierarchy of Needs; meaning its in response to the idea that man is constantly a needing/wanting being. This falls right in line with my (currently unpublished) research on three dimensional organizations. My research states that each organization must balance quality assurance, stakeholder experience, and efficiency. External to each of these three dimensions are the needs and expectations of various environmental forces (economics, psychology, morality, etc). While we may not all agree upon the wording applied in a definition this lack of specific agreement is because each entity with a need/want for a specific thing of quality will express that need/want differently thus requiring a modifications to the definition. The ISO standard is an excellent reference for this subject because it begins by discussing the origins of the definition based upon the philosophical understand of an individual or an organization’s need.

To capture quality assurance requirements within an organization one must understand not just the stakeholder’s stated positions of needs/wants, but also the principles behind those decisions. The difference between the two is articulately discussed in Fisher and Ury’s classic negotiation text, Getting to Yes.