Understanding the Matrix of Processes

written by: Dave Caccamo on October 12th, 2015

A common mistake PMP applicants make is to view the matrix of processes (shown on page 61 of the PMBOK Guide and below) as a set of activities.  They attempt to construct some sort of dependency network of processes as part of their efforts to understand how all the project parts fit together in the real world.  Their motives are understandable, but in doing this they run the very real risk of seriously misunderstanding just what the processes are.  The principle difference between an activity and a process is that processes are logical constructs that describe project functions in the abstract (and often pulled out of actual context).  Unlike activities, they are not a set of tasks that follow one after another.  Logical constructs (as abstractions) can not only be done concurrently, they can also be viewed as integral parts of a bigger whole.

pmbok map

For example, you look over at your cubical mate and (once again) he is asleep.  Being the conscientious team member you are, you diplomatically wake your workmate before the customer should stumble upon him.  Looking at page 61, what process did you just accomplish?  Well obviously by waking him you have helped to keep the project on schedule (Control Schedule), but have you not also in some way kept the project on budget as well (Control Costs)?  And would it be a great stretch to also say you in some way, shape or form you also were implementing a corrective action that puts you firmly in Direct and Manage Project Work?

In other words, while it may be helpful as part of your initial studies to view project processes as activities, please remember they are actually processes.  When this difference is clear to you, it is a good indicator that you truly understand an essential purpose of the PMBOK Guide.


PDU Change From PMI and What It Means For You!

written by: Tom McGraw on September 29th, 2015


PMI is making changes to their certification programs that will affect PDUs provided by their Registered Education Providers (REPs).  The new program was launched based on PMI analysis, determining that a sole focus on technical skills for PMI credential holders is no longer sufficient for what the individuals face in their day-to-day work.  The new program, emphasizes not only the need for technical training, but now also requires a set number in two new categories: Leadership and Strategic/Business Management.

For individuals with a certification expiring prior to November 30th, 2017, you are still held to the previous model, requiring 60 total regardless of categorization in one of the three areas of the Talent Triangle.  Once you do renew your certification in that time frame, you will be held to the new standard for your next cycle.

Click to continue »


3 Levels of Leadership for Agile Transformations

written by: Melody Yale on August 26th, 2015

businessagilitySelf-organizing teams rely on several levels of leadership in order to be successful. Business Agility is not just a “nice to have”. It’s a competitive advantage for leaders and organizations. Being able to adapt quickly in order to respond to new market problems is what separates the winners from the losers. But actually transforming an organization from a waterfall methodology to an Agile delivery model is tremendously hard. It can be a thankless and lonely job. There are hurdles to overcome and people will push back. Agile transformations can fail because leaders do not have the emotional wherewithal to finish the job.

Why is it so hard?

Agile development requires change in culture, people and process. When you are transforming at the organization scale, you are removing the stability that people have come to know and love. You are changing their roles and responsibilities and you are changing the process by which their success is measured.

Click to continue »


How Agile Development Increases the Team Happiness Factor

written by: Melody Yale on August 24th, 2015


I worked with a company that used the acronym- WOW. Sounds like it should be fun, but it meant “work on weekends”. Unfortunately this happened more often than not. Teams would scurry around to complete work in the last hours before the release because inevitably software developers were over-committed. The problem wasn’t necessarily with the software development teams, yet they were the ones that suffered. The whole process was broken including the fact that scope was inflexible and the date was set. And of course the mind-set was to deliver everything that was committed to on the date that was set- a year ago. This results in lots of tension between the business, project management and software development. It also results in a “just get it done” attitude. Well, that’s no fun.

In Agile development we value working at a sustainable pace. Most people value work/life balance as an important aspect of their job. When people are happy with their jobs, they are more likely to be productive and stay with the company.  According to a recent survey by Staples, job burnout is a major reason why people begin to job hunt. It’s no secret that turnover is costly to an organization. Not just because you have to recruit and hire someone to replace the person who left, but because the person who leaves takes with them an enormous amount of tribal knowledge that is valuable to our projects.

As servant leaders we have an impact on the work/life balance of our teammates. As ScrumMasters we can coach members of the team to not take on more work than our stated capacity. We can discourage a culture where we brag about working 70 hours a week or regularly do not take lunch breaks. ScrumMasters can coach team members on how to manage their schedule so that they are able to maintain a sustainable pace. They should have some time for lunch or take a brain-break during the day.  As Product Owners we can respect the average velocity of the team and plan for it- so we can set expectations for what is actually achievable. We should respect each team member’s time off and be mindful to not request more than necessary.

A sustainable pace goes hand in hand with a fun workplace. We should make it a priority to have fun with our teams, as that simple act of bonding makes us more empathetic to individual needs. Also because a fun workplace is just a better place to be. You rarely hear someone leave a job because they were having way too much fun. And while we’re trying to recruit the best and the brightest, we must consider what job aspects matter to the new workforce.


Web Seminar Recap: Lean Analytics Overview

written by: Admin on August 21st, 2015

Lean Analytics supports Lean Startup by measuring and analyzing data as you progress, with a focus on data-driven decisions.  Lean Analytics works in conjunction with Lean Startup, which challenges traditional approaches and shows how traditional ways of measuring a project does not work in a startup situation.

On August 21, 2015, Robert Tyson presented a 1-hour web seminar on Lean Analytics and its role in Lean Startup. He discussed topics such as:

• Innovation Accounting
• Lean Analytics Stages
• Vanity vs. Actionable Metrics
• The One Metric That Matters

Missed this web seminar? Catch up by downloading the presentation slides and recording here.


The Minimum Viable Product

written by: Robert Tyson on August 18th, 2015

Leveraging the Minimum Viable Product in new product development

mvpOne of the practices used in Lean Startup is the Minimum Viable Product or MVP. The MVP is the most basic version of a product. It is aimed at extracting feedback from customers, or potential customers, based on specific product experiments. The idea is to look for evidence of demand before building a complete, functioning product.

For the entrepreneur, the MVP is a valuable tool to gain insight into a new product or a new growth market. Leveraging the Lean Startup Build-Measure-Learn cycle, a properly executed MVP drives product development and provides valuable data for pivot or persevere decisions.

The MVP should be viewed as a process, not a product. Building rapid iterations of the MVP, measuring results, and learning from those experiments requires discipline – it requires a process to be successful.

The MVP goal is to execute the fastest turn of the Build-Measure-Learn cycle as possible, with minimum effort, and minimum development. Doing this allows the entrepreneur to start learning as quickly, and as frequently, as possible.

When designing an MVP, each version should have just enough features to test out the hypothesis. Any work performed beyond that goal is a waste. MVPs are used to test product design or technical questions, test fundamental hypotheses, and extract feedback from customers. Through the MVP, the entrepreneur learns the features the customer really wants.

A frequent mistake is to overestimate the needs for the MVP. If there is any doubt, then simplify. Having too many features can make the analysis of the results difficult. How do you know which change actually drives behavior? Too many features may also create a premature maintenance overhead as you try to maintain what you have deployed. Keep the features simple and targeted. Any features beyond that is a waste of resources.

An MVP helps to clarify the conflict between what customers say versus the actions they actually take. The customers’ actions when using the MVP may contradict what the customer stated as their top priorities. Be sure to include methods to capture metrics in the MVP.

The MVP may also end up in bad news. It may prove that a basic hypothesis does not hold up. This information is critical in decisions to persevere on a product’s current path or pivot, and find a new hypothesis. It requires courage to put your assumptions to this sort of test. However, finding out early prevents wasting resources in developing the wrong product and, often more importantly, prevents the lapse of precious time.

An MVP is not always software. The new innovative item may be a service offering or retail product. Regardless, ideas need testing before building massive amounts of infrsatructure. Simple tests often suffice. Published examples include:

  • Groupon – initial MVP was email, PDF files, and the bar in their building
  • Food on the Table – personally delivered food and created recipes with a single customer
  • Aardvark – manually answered searches

The Food on the Table MVP is an example of a “concierge MVP”. In this type of MVP the initial customers are given special treatment – sometimes unbelievable treatment! In the Food on the Table example, there was initially just one customer. The entrepreneur personally went to the customer’s house to develop recipes and deliver groceries. If you test your hypothesis using concierge treatment and the results do not look promising, then you need to re-think your strategy!

The Aardvark MVP is an example of a “Wizard of Oz MVP”. The hypothesis was tested by manually executing “behind the curtain”.

Neither the Concierge MVP nor the Wizard of Oz MVP is a viable, sustainable approach as a long-term solution. The key aspect is that the entrepreneur learns valuable lessons that would be difficult to duplicate by other means. Validate the leap-of-faith assumptions early before the significant investment of time and money.

Often considered low quality, software MVPs may challenge the developers’ traditional values around quality. These MVPs are designed to perform specific experiments, not produce a polished final product. The target customers are often early adopters who see the potential for breakthrough products. They are more forgiving of mistakes and suspicious of anything that appears as too “polished”.

The Minimum Viable Product is an entrepreneur’s tool for rapidly gathering customer feedback about a proposed product or service. The MVP is used to validate initial assumptions and to guide product development. It provides valuable information about strategies and when a pivot may be in order. When developing an MVP, be clear about what you want to learn and how you will measure it.


Robert Tyson (PSM, ITIL) is a veteran IT professional with over 35 years’ experience in both domestic and international environments. He is currently an Agile Coach and Instructor with Agile Pi.


What are Your Software Development Guiding Principles?

written by: Melody Yale on August 17th, 2015

Software development has changed a lot since the 1990′s. Project Managers used to spend a lot of time planning, designing and estimating only to find that six months into a project the inevitable happened- the requirements changed. Spending time on more documentation led to failed projects and frustrated Project Managers. There had to be a better way!

Agile development principles were built upon years of best practices. We often spend a lot of time stressing the importance of a few development principles when we coach teams transitioning to an Agile delivery model. Let’s explore how a few of the principles have changed our processes.custom_software_development1

Instead of the frustrating scenario above, Agile development welcomes changing requirements, even late in development. We’re able to accommodate this because the product owner reserves the right to prioritize the backlog frequently. If a customer has an emerging requirement that is the most valuable of all requirements, then the product owner is able to schedule it appropriately. This creates the perception of faster innovation and is truly a competitive advantage for you and your customer.

Working software is the primary measure of progress. By working software we mean that we will produce a shippable increment of software each sprint. In order for something to be shippable, it has to meet some criteria set forth by the team. The definition of done is the checklist of that criteria. What does done mean? Done is an ambiguous term and inconsistencies are often uncovered in sprint review. Are you done with programming? Are you done with QA? Have you documented this new feature?

When we’re delivering working software frequently we need to make sure we agree on what done means for three reasons. First, we don’t want to kick un-done work down the road by rolling over tasks to the next sprint. Second, if we’re not completing the work in our sprints, then we cannot count the time toward our velocity. Velocity is important because it’s used to estimate how much work can be completed in a sprint and helps product owners create a forecast for the release. Third, the definition of done is an agreement of the team to ensure a consistent level of quality for each shippable increment.

Speaking of quality, being consistent with a high level of quality each sprint is important. Have you ever worked on a software product that had a ton of technical debt? Customers can’t appreciate the good work you’re doing if they can’t get past the bugs, performance problems, and bad design. Bad quality is expensive. Fixing bugs is disruptive and expensive not just for the software development team, but for the customers who use the software and who may have to spend their time updating the software. Since satisfying customers is our highest priority, Agile development best practices recommend quality over quantity for this reason. Quality is controlled by a heavy emphasis on a test driven development approach and automated tests that run at regular intervals throughout the development process.

Now with globally dispersed teams and the internet of things creating greater demand for software, we can’t afford not to be Agile. The Agile principles pave the way for better software development. Other than the Agile principles what guiding principles do you need for your Agile development delivery model?

For a full list of all 12 Agile principles you can access them here.