4squareviews

On Friday, I went to a local bookstore and got Benny Lewis’ book Fluent in 3 Months.   I decided to take the day off in terms of my usual blogging about project management, and set forth my goals in general and for the next month in terms of language learning.

This is because over the weekend I was reading Fluent in 3 Months, and after reading the chapter on why people should be endeavoring to be fluent in multiple foreign languages, he starts the next chapter by challenging people to set actual goals that are specific and to post those goals in a public place (like a blog post) in order to make oneself accountable for them.

1.  Multilingual level goals

I am fluent in five foreign languages if you measure that fluency in terms of B1 level or higher on the Common European Language Framework.

So for those languages, I have put my goal to become one level higher by 2017.

For the languages I have been studying but which I have not achieved fluency, I am also putting my goal to become one level higher by 201

For those languages I have not studied before, but which I want to study in 2016, I’m putting the target as BEGINNER (A1).

Although I put all languages on my level goal list, certain languages have higher priority level, which translates into studying frequency.   Also, although my ultimate goal is to speak with native speakers, my intermediate goal  is to use textbooks in order to prepare for proficiency tests.

2.  Multilingual goals–method, priority level

3.   Multilingual goals–March 2016

Here’s my goals for March 2016.

Those languages which are in bold are high priority, those that are in regular font are medium priority, and those which are in italics are low priority.

Let’s see what I accomplish in the month of March!

Filed under: Uncategorized | Leave a comment »

This post is one of several describing a single process that is essential to controlling an agile project, namely Earned Value Management.   It is labeled 2.13 on the agile project management process grid because it covers the second knowledge area of “Value Driven Delivery”, which monitors how the project manages the constraints of time, cost, scope, and value; it also is the thirteenth process in that knowledge area.   In particular, it is one of the processes done during the “Control” process group in any given project.

This post is the last of five describing the process 2.13 Earned Value Management.    The posts have covered

• the similarities between Earned Value Management on a traditional, waterfall project, and an agile project
• the differences between Earned Value Management on a traditional, waterfall project, and an agile project
• the way that Earned Value Management is measured in an agile project using traditional reporting metrics of Earned Value (EV), Planned Value (PV), and Actual Cost (AC)
• the way that Earned Value Management is reported on an agile project

Today’s post covers some non-traditional reporting metrics for Earned Value Management in an agile project environment.

Using the three building blocks mentioned above, you can get the following four metrics that show how a project is doing with respect to the schedule and budget:

Schedule Variance and Schedule Performance Index both tell you the same thing, that is, whether the project is on time or not, but they do it with different sets of numbers.    An SV that is positive means that the project is ahead of schedule (i.e., you’re completing more work than planned), and an SV that is negative means that the project is behind schedule (i.e., you’ve not completed all the work you planned).   An SPI tells you this as well, but the SPI that is greater than 1 means that the project is ahead of schedule, whereas an SPI that is less than 1.0 means that the project is behind schedule.

The Cost Variance and Cost Performance Index in a similar way show whether a product is under budget (with a positive CV or a CPI that is greater than 1.0) or over budget (with a negative CV or a CPI that is less than 1.0).   Those are the traditional EVM metrics, that can be used in an agile project as well.

Here are some EVM metrics that are strictly geared for agile projects.    They are based on the assumption that progress should be measured against the release level (not the iteration level), and that A-EVM calculations are done at the end of each iteration.

However, these calculations are not universally accepted within the agile community, which just goes to show that agile project management is definitely a work in progress.

The next post will discuss the process 3.20 Information Radiators Monitoring.

Filed under: Uncategorized | Leave a comment »

This post is one of several describing a single process that is essential to controlling an agile project, namely Earned Value Management.   It is labeled 2.13 on the agile project management process grid because it covers the second knowledge area of “Value Driven Delivery”, which monitors how the project manages the constraints of time, cost, scope, and value; it also is the thirteenth process in that knowledge area.   In particular, it is one of the processes done during the “Control” process group in any given project.

This post is one of several devoted to the process 2.13 Earned Value Management.    The last post covered how to track and report Earned Value Management.   This post will cover the issue of the granularity of reporting.

The biggest difference between calculating planned value in traditional and agile project management is that in traditional project management, planned value is usually calculated as the cumulative value of the work that is scheduled or planned to be completed by a certain point in the project.    The planned value at the end of the project, for example, will just be the amount of the budget of the entire project.

This is true in principle in agile project management, except that the value is calculated, not in terms of dollars, but in terms of the number of stories completed.   This number of stories complete is based on sizing, an agile estimation technique which gives the relative size of the effort given to complete a given story.    In traditional PM, the estimate is based on the absolute dollar value of the work involved in completing a given work package.

The planned value can be based on the roadmap, the release, or a given subset of iterations.   What level of granularity should be chosen?

Just remember that the greater the level of detail of the estimate of planned value, the greater amount of resources required to create that estimate.

A Parable on Estimation:  the Cartographer’s Tale

This takes me to a parable, taken from a short story by Jorge Luis Borges in the collection Dreamtigers.   There is a village in Germany which is well-known as having one of the most ambitious set of cartographers in the country.   They created a map which had a 10,000:1 scale.   They decided to try for 5,000:1 scale map.   They succeeded, and went to go for an even smaller-scale map. 

Eventually, they told the mayor of the town that they were going to go for the ultimate map, a map that was on a 1:1 scale!    They told the mayor that such a cartography project had never been attempted before, and, if successful, would bring tourists from around the country to view it!

The mayor agreed and put all the town’s resources into the creation of the ultimate map.   Many projects that would have been carried out relating to the upkeep of the town were put on hold, in anticipation of the future revenue that the creation of this map would bring.    The mayor said that the map would be revealed to the world at an unveiling ceremony to be held at the Town Hall!    He invited dignitaries from around the country to be there for the ceremony.

On the day the map was created, however, the cartographers came to the mayor with distressing news!    The map was understandably so large that it could not be folded into a shape compact enough for it to even get out of the door of the cartographer’s building.   With no map to show for all the effort, the mayor was embarrassed, and the town’s finances were now known to be in a shambles because the resources had all been used up for the creation of a map which was practically useless.    That night, the cartographer’s building, and the map inside it, burned up in a mysterious fire.   Whom it was set by was never revealed …

Okay, I embellished the short story a bit for dramatic purposes, but the meaning is clear.   The amount of resources put into the map exceeded the actual value that the map was creating.   The example of the map is a reductio ad absurdum intended to show that the VALUE of the estimate to the project must exceed the VALUE required to create it.   So if you only need to go to the level of the release plan, or even a certain subset of iterations that achieve a certain milestone, so be it.   That’s what the level of granularity should be!

Since the measure of planned value is based on the relative value of the size of the effort required, rather than the absolute (dollar) value of the effort, the way that earned value management is expressed can differ between traditional and agile management.

There are other A-EVM measurements than Earned Value (EV), Planned Value (PV), and Actual Cost (AC), and these are discussed in the next post.

Filed under: Uncategorized | Leave a comment »

This post is one of several describing a single process that is essential to controlling an agile project, namely Earned Value Management.   It is labeled 2.13 on the agile project management process grid because it covers the second knowledge area of “Value Driven Delivery”, which monitors how the project manages the constraints of time, cost, scope, and value; it also is the thirteenth process in that knowledge area.   In particular, it is one of the processes done during the “Control” process group in any given project.

This post is one of several devoted to the process 2.13 Earned Value Management.    The last post covered the processes of Earned Value Management, and how these are differ in waterfall and agile projects.

How do you report on EVM in an agile environment?   That is the subject of the current post?   Remember, the key quantities to report on are:

Filed under: Uncategorized | Leave a comment »

This post is one of several describing a single process that is essential to controlling an agile project, namely Earned Value Management.   It is labeled 2.13 on the agile project management process grid because it covers the second knowledge area of “Value Driven Delivery”, which monitors how the project manages the constraints of time, cost, scope, and value; it also is the thirteenth process in that knowledge area.   In particular, it is one of the processes done during the “Control” process group in any given project.

This post is one of several devoted to the process 2.13 Earned Value Management.    The last post covered the fundamental building blocks of Earned Value Management, and how they are the same in both waterfall and agile projects.   The process of earned value management, however, differs in waterfall and agile projects, as can be seen from the chart below, where EVM stands for Earned Value Management in a traditional or waterfall environment, and A-EVM stands for Agile Earned Value Management.

The only process the two have in common is the second, Assemble Team.   When I first saw this chart in John Stenbeck’s book, I was wondering why it was even there because it is considered to be a human resources process in the PMBOK Guide.   I believe it is there because John Stenbeck wanted to emphasize that the process of earned value management should be a team effort.

How do you show EVM in an agile environment?   That is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

John Stenbeck in his book “PMI-ACP Exam Prep PLUS Desk Reference”, he creates an agile project management process grid with 87 processes divided into 5 process groups and 7 knowledge areas.

This post is one of several describing a single process that is essential to controlling an agile project, namely Earned Value Management.   It is labeled 2.13 on the agile project management process grid because it covers the second knowledge area of “Value Driven Delivery”, which monitors how the project manages the constraints of time, cost, scope, and value; it also is the thirteenth process in that knowledge area.   In particular, it is one of the processes done during the “Control” process group in any given project.

The tool of earned value management will requires several posts to discuss; in the first, let me discuss the general utility of earned value management in project management in general BEFORE we discuss how to apply it to agile projects.

The three triple constraints on a project are time, cost, and scope.  There may be additional constraints in terms of quality, risk, etc., but in the end, they all boil down to the three basic constraints.  Earned value management is considered by many in the project management community as the best option currently available for holding all parties accountable for the effective management of large and complex projects.

It does this with three “building block” variables of earned value management:

• actual cos (AC), which monitors the actual cost of work  done;
• planned value (PV), which monitors the value of work that is planned or scheduled to be done, and thus is a measure of time or schedule;
• earned value (EV), which monitors the estimated cost of the work actually accomplished or completed, and thus is a measure of the scope accomplished.

Earned value management takes these three building blocks and calculates cost and schedule variances.

The project manager’s job is to analyze those variances and use to:

• identify those sources that are enabling or hindering project progress
• forecast future cost and schedule performance issues
• define appropriate corrective actions and preventive actions to improve the probability of project success

The basic building blocks, and equations of Earned Value Management are the same in both waterfall and agile projects.   The next post will compare the similarities between the process of EVM and EVM in an agile environment, which we will abbreviate by A-EVM.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

This post concerns the process of controlling agile contracts that were entered in process 2.3.

An agile contract is one that is designed for an agile project management environment.   In my last post, I discussed the three different types of contracts in traditional project management to give a contrast to the agile contracts discussed in this post.

Traditional PM Contract Types

As a recap, here are the three types of contracts used in traditional PM.

Three Types of Contracts in Traditional PM

The three types of contracts in traditional project management are:

1. Fixed price
2. Time & material
3. Cost reimbursable

In terms of cost risk, you can list the three types of contracts in the following way, where a higher cost risk to the seller is to the left, and a higher cost risk to the buyer is to the right.

Fixed Price –> Time & Material –> Cost Reimbursable

Fixed price contracts tend to be used when the scope is predictable, and thus a fixed price is readily obtained for the component.   Cost reimbursable contracts, on the other hand, are used for when the scope is NOT so predictable, and thus the cost of the component cannot be so readily obtained.

Inherent in the fixed price and cost reimbursable contracts are the tension between the seller and buyer in terms of cost risk; fixed price favors the seller and cost reimbursable favors the buyer.   That is why there are mechanisms in place (ceiling price, incentive fee, etc.) to make the cost risk more equitable on either side.

Agile Contracts Types

In agile contracts, on the other hand, all three types try to balance the cost risk between seller and buyer, and the difference comes to not how they are structured in terms of cost, but how they are structured in terms of time.   Agile iteration contracts are done for the duration of an iteration.  Time & Material contracts are done for an arbitrary period of time.  Phased development contracts are done on a quarterly basis.

One feature that agile contracts have in common with traditional PM contracts is that they tend to be risk management tools.   In the case of traditional PM, the focus is primarily on cost risk.

1. Agile Iteration Contract–this is based on each team delivering agreed upon features to defined quality standards by iteration end.   NOTE:   The Product Owner is NOT allowed to change the iteration backlog DURING the iteration.
2. Time & Material–this is based on a customer continuing to pay a customer during an agreed-upon time period until such point that the customer doesn’t see value being added, at which time the customer stops paying and the contract ends.
3. Phased Development–this is based on the team achieving a successful release of the product.

In agile contracts, cost risk is a factor as well, and the time period of the contract is chosen based on the needs of the customer and the size of the project, but the agile contract helps manage other areas as well.   Here is a chart showing how the four areas of scope, risk, communication, and cost management (related to issues of invoicing and payments) are dealt with in the three types of contracts listed above.

The overall point to remember with agile contract is that the relationship between the customer and team is paramount; the contract is merely a formalizing of that relationship and a way of dealing with risks that may occur in the future so that the customer and team can essentially put them aside and focus on their working relationship in the present.

Controlling Agile Contracts

The first word that should come to mind when thinking of the word “controlling” in project management is the companion word “monitoring”.   First you monitor to see if the contract is being carried out as planned, and then if it isn’t, THEN you control the situation, either bringing it in line with the contract or modifying the contract as necessary.

The key point is that, just with traditional project management, a contract divides the shared risk between the parties and thus defines what the pressure points of trust are between them.

The best practice in monitoring a contract is to define a small number of high level user stories that include acceptance criteria that are the conditions of satisfaction for each story.   The conditions of satisfaction need to be discussed during the process 2.3 so that the development risk can be seen as adequately being covered and equitably being shared in the course of the agreement.

Any effort spent defining the conditions of satisfaction will pay for itself in the time and cost avoided having to mitigate any undefined requirements later.

Another element of good contract control is good estimating, so that both parties can realistically determined the amount of risk each party is sharing.

Periodically monitoring the contract is not questioning the trust of the parties; it is building a solid foundation so that such trust can be built upon during the course of the project.

The next post covers the issue of earned value management in agile projects.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

This post covers Accounting Control, one of two parts of process 2.12 (the other one is Contract Control).

Accounting control is measuring performance against a cost baseline, which is created in the following steps:

1. Create a release plan
2. Forecast cost per iteration
3. Establish a cost baseline

However, at the end of each iteration, just like the grooming of the product backlog, the cost baseline should also be reviewed before each iteration and re-calculated based on any changes made to the product backlog (which may effect step 2 above) or the release plan (which may effect step 1 above).

If an earlier cost estimate has been decided to be mistaken, then the team needs to alert the Product Owner or customer/proxy to discuss the implications so that proper decisions can be made.   Any changes must be negotiated with and approved by the customer/proxy.

For most organizations, doing accounting control at the release level is not enough; it must be done at the story level in order to get control of the cost baseline.

The other type of control that must be maintained is that of Contract Control, which is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

I am now covering the set of processes done in the control process group of an agile project, specifically those processes that have to do with the knowledge area of Value-Driven Delivery (equivalent to the “Quality” knowledge area in traditional waterfall project management).

In the last process 1.11 Product Demonstration, a validation process is done prior to a Release of the project.   Thus it has the same goal as a Review meeting, but is obviously at a higher level of importance because it is done prior to the Release of the product to the public.

Well, if you show the stakeholders the product, there are two possible reactions:

• hey, that’s just what we asked for!
• wait a minute, that’s not exactly what we asked for

And I suppose a third possibility is, “hey, that’s just what we asked for before, but since then we’ve changed our minds.”   In any case, if there are certain features of the product which do NOT meet the satisfaction of the stakeholders, then the process 2.11 Product Feedback gives the stakeholders the chance to stake specifically what needs to be changed in order to meet their expectations.

This will send the team back to revise the product according to the new shared understanding of the requirements as set forth by the customer and interpreted by the team.

The next post will go to the next knowledge area, that of Adaptive Planning, to see what takes place in an agile project during the control process group that is related to that area.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

I am now writing about those processes that occur during the Control process group.    The first process is one that deals with the first knowledge area, that of Engaging External Stakeholders.

In process 6.7 Review Meetings are done at the end of each iteration.   Product demonstrations are, like review meetings, product-centric presentations of completed work products.   However, they are done not at the end of each iteration, but prior to a Release.    The purpose is get feedback from the stakeholders that validates the value that the team has created for the end user.

Like the review meetings, features are demonstrated that were actually completed, and any features that were not completed are documented, along with the reason why they were not completed.

The purpose of the meeting is to align the team and the stakeholders so that a sense of trust is fostered which allows the team to remain focused on the goal of the Release.

The next process is actually part of the same Product Demosntration, but done for a different purpose, for value-driven delivery.  That is process 2.11 Product Feedback.

Filed under: Uncategorized | Leave a comment »