Gaining Perspective Through Project Assessment Meetings

In rigid agile frameworks such as scrum a sprint review isn’t just a good idea, it’s required.  In this meeting the team reviews the product’s progress and captures feedback used to lock in existing work and develop new work.  It’s a great technique and when scrum can be followed precisely it adds a lot of value to the process.

But what about those projects that are conducted using a hybrid methodology?  Not every project is an ideal setting for using agile methodology.  Agile principles still get pulled into the projects, but sometimes the rigidity of agile structure is left behind.

One technique I apply is conducting a Project Assessment Meeting.  Now, let’s be clear.  I’m not a fan of meetings that have no purpose.  This isn’t just a nice way to spend time, it’s opportunity for learning.  Project Managers can easily get focused on task management and start missing their perspective on delivering value to the client.

The purpose of the Project Assessment Meeting is to create a dialogue that helps restore that perspective.  At appropriate intervals I’ll ask to meet with a client (Product Owner) and discuss in general terms their perspective of the project.  I find it best to ask open-ended questions that encourage them to respond in a story-telling format.

When you tell the story of this project to others what are the highlights?

How do you describe the project’s progress?

What was the biggest struggle for the team since we last met?

From the responses to these questions I can generally get an understanding of the challenges facing the client and how they see the project.  Because they’re open-ended it requires me to do a lot of active listening helping to create an environment of trust and openness.

I use the responses from these questions to ask for more poignant details.  My follow-up questions are designed to seek out successes, obstacles, and bottlenecks.  I look for successes because the PMs that I work with are extremely passionate about delivering a quality product.  They want to hear unbiased feedback that the client has seen that value.

Next I look for obstacles.  I believe the that the single largest responsibility of a leader (after make decisions and accept risk) is to remove obstacles.  The world would be a better place if every leader saw their day-to-day as a fight to remove obstacles from the teams they lead.  I’m looking for those obstacles with the project and work with all the stakeholders to develop techniques and practices to remove those obstacles.

The final clues I’m looking for involve bottlenecks.  Bottlenecks are natural consequences of a production cycle.  They’re not inherently bad.  They are inherently powerful.  Recognizing and controlling a bottleneck allows the production to focus on increasing their throughput and focus their attention where it matters most.

In many cases some of the junior clients we’ve worked with prioritize their backlog based upon features they have a personal investment in.  One way to tell if a client uses this prioritization method is if the priorities shift often during the project.  When the system for determining business value (priority) is based upon interest it can change quickly.  These backlogged features may or may not be items that increase the throughput of their workflow.  In this situation, I’ll take the time to help the client identify their bottlenecks and discuss them with their team as a neutral and natural consequence–not a failure of any particular team member or workstation.  Next I’ll introduce them to the theory of constraints and coach them in applying this theory in their environment.

At the end of the conversation I follow-up with an email to our stakeholders thanking them for meeting, documenting what was discussed, and offering encouragement going forward.

I don’t like meetings that don’t have a purpose.  The intent behind this meeting is to establish an environment where information is exchanged that helps the project team maintain their perspective on the project’s purpose.  I find that in-person meetings are a highly productive method for helping the project team maintain this perspective.

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.

Idaho Character

For over a year I’ve been proud to be a part of one of the greatest teams you’ve probably never heard of. I work at the Boise Military Entrance Processing Station (MEPS). There are 65 MEPS across the country and each one assess the aptitudes, physical capacity, and background history of the young men and women wanting to join the armed service of their choice. It’s not possible without the great crew dedicated to fairly applying DoD standards as efficiently as possible. Boise continues to rank among the top-tier across the nation for efficient processes and customer service.

One of the many roles includes serving as the swear in officer. A few times each day I ask these young men and women to raise their right hand and repeat the words of the oath of enlistment.  At this point I’ve conducted several hundred of these ceremonies and enlisted more than 1,900 people into the service.  It didn’t take me long to memorize the oath of enlistment:

I, _____, do solemnly swear (or affirm) that I will support and defend the Constitution of the United States against all enemies, foreign and domestic; that I will bear true faith and allegiance to the same; and that I will obey the orders of the President of the United States and the orders of the officers appointed over me, according to regulations and the Uniform Code of Military Justice. So help me God.”

The transition into military life isn’t for the faint of heart and the oath isn’t for those of thin character.


An applicant who enlisted in the Marine Corps wearing his tribe’s uniform.

At the end of the oath ceremony I’ve been asked several times to pose for a photograph with the military’s newest enlistees. I gladly comply if asked, but over the months and weeks I’ve learned to have the applicant stand with the seal of their chosen service in front of the nation’s flag. I call this the “Mom Photo” because it’s the photo that moms are happy to post of their children.  If parents aren’t available the recruiters will step in as the photographers and send the photo later to the enlistee’s family.

For several weeks I had been teaching recruiters to take and share these photos when something out of the ordinary happened.

It started with quite a normal scene.  I walked into the ceremony room with our red carpet and inside were two applicants, a young man with his family and a young lady with her recruiter.  They were both dressed respectfully and immediately went to attention when I walked in the room.  (This is done out of respect for my authority as an officer and the oath, not who I am as a person.)

The young lady, sharp as a whip and ready to go, finished the oath and stood proudly as her photo was taken.  In the process of helping her pose for the photo I explained that I nicknamed the photo, the mom photo and suggested she send the picture to her mother.

Her countenance quickly changed. I could tell I created a difficult moment in her life. I wasn’t sure what I had done wrong, but after taking the photo I stepped out of the room and she remained in the room with the other applicant and his family.

When I saw her next to sign her paperwork I could tell she had been crying. My heart sank. I felt that I must have done a terrible thing. We finished the paperwork for both applicants and I stood up to walk down the hall to follow-up and apologize.

One of the recruiters stopped me and he too had an emotional expression on his face. He told me what happened after I left the ceremony room.

The young lady shared that due to her mom’s poor choices her mom was living over 2,000 miles away and not a part of her life at the moment.   She said she wouldn’t be sending the photo to her mom.  When she was coming back in a few months to ship for basic training mom and dad wouldn’t be there.

The other family heard this and without hesitation stepped in and offered to attend the ceremony and write the young lady while she’s off at basic training.  One moment she didn’t have a bit of family in the room.  The next she had been adopted by one of the many families I’ve seen in that ceremony room during my time administering the oath.

That day’s circumstances were extraordinary, but I think extraordinary is typical of the people in this state.

In my official capacity it would have been inappropriate for me to write down names or dates.  You see, she leaves to put on her uniform after I’m done wearing mine.  I don’t remember when she’s coming back to ship out for basic training, but I know that people in this state mean what they say, and say what they mean.

Somewhere in Florida there’s a mother out there who’s unaware that her daughter is being loved, and I couldn’t even tell you who’s doing it, but I don’t know of anyone I’ve met at the MEPS who wouldn’t have stepped up and done the same thing as this family.

There’s an obscure regulation in the MEPS that advises me to share some life advice before administering the oath.  Sometimes I tell the applicants in front of me that the State they represent when they go off to start their careers might be famous for its potatoes, but the real gems of this great State are the people.


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.

Spanning The Emotional Range

It’s not often an artist can lead an audience through such a wide emotional range in such a short amount of time.  When that happens it’s worth sharing.  Lindsey couldn’t have done it without great material to work from and so I’d love to say congrats to all the teams that made this sweet little video possible.

It just made today a whole lot better.

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.

A Step Closer to IPO

The rumors aren’t verified, but they’re not really hiding either. The tech press at ZDnet ran an article last year, and Bloomberg even noticed in December. Something’s brewing over at Canonical and the game just got another push forward.

Canonical Ltd. is is a British company that creates the most popular server software in the world (Ubuntu) enabling large portions of the internet to function. The company’s strategy for software releases includes long term support (LTS) versions and shorter release versions of its software. The LTS versions are supported for security and features for 5 years. Ubuntu 18.04 (due in April of 18) is projected to be a significant LTS release incorporating new technologies and positioning the company towards a more productive future. It’s owner, Mark Shuttleworth, is rumored to be taking the company to an IPO and 18.04 is rumored to play a significant role in the IPO process.

Ubuntu has been operating nearly blindly not knowing who their customers are. It tracks metrics for full software and patch downloads, but does not know how many systems those downloads are associated with. They recently announced the release of their latest update and a new feature to collect user data to better understand their consumers and how to precede. They are interested in collecting data on the preferred “flavor” or variations, the versions, hardware specifications, country of origin among other statistical data.

This data collection will give Ubuntu answers it needs to be able to answer future investor’s questions. One of the big questions with this feature roll out is whether or not the users will play along. Ubuntu and the open source community is known for being more security aware than the average user. Whether or not they see this as an invasion of their security remains to be seen.