The Agile PM Blog

Continuous Delivery: The Ultimate Challenge for Software Development Managers

By Kevin Aguanno, PMP, MAPM, IPMA-B, Cert.APM, CSM, CSP
and Mike Bowler, CSM

In a recent article titled “Agile Methods and The Need for Speed”, the author notes that many people are adopting agile development methods in hopes that they can deliver their project faster. The article goes on to state that, while speed is a possible outcome of agile methods, it is not guaranteed. Agile projects are more likely to achieve other benefits first, such as reduced technical risk, higher quality, greater likelihood of meeting true requirements, and more. Yet there are still those elusive speed-related benefits that people strive to achieve in their first agile projects.

To truly deliver software faster, one must look towards cutting down the timespan of all processes in the software development lifecycle from requirements gathering to deployment. Many who seek faster delivery use agile methods to improve the requirements gathering, design and development processes but are frustrated in their attempts to get a speedier deployment of the new software. These people often see deployment activities as unnecessarily cumbersome and often without much perceived value.

Perhaps the agile community has contributed to this perception. We have talked about concepts such as “continuous deployment” for years as if it were just one of the many agile techniques we can employ on our projects. Yet, this particular technique stands apart from many of the other basic agile techniques such as holding daily stand-up meetings, managing requirements using backlogs, and breaking a project down into iterations which culminate in a demonstration to stakeholders. Continuous deployment is among the most difficult of agile techniques to employ successfully and requires a very high level of agile maturity and discipline in the team.

Generally, to be successful at continuously deploying software into a production environment, a number of preconditions must be met:

Automated Builds – The team must have tooling in place to automate their software builds. In addition, the team must follow consistent coding standards to help facilitate the automated builds. For continuous deployment, there is no time to waste manually integrating source code from various developers into the official build.
Automated Regression Tests – Every time an automated build takes place, there should be software in place to execute a suite of automated regression tests to make sure that the existing deployed software is not impacted negatively by the new code. Some automated build tools can execute “smoke tests” or a partial suite of lightweight regression tests to verify basic functionality. For full regression testing passes, however, you will likely want to take advantage of a separate, dedicated automated testing solution.
Automated Compliance Scans – In some environments, after the software development team determines that a high-quality package of software is ready for deployment to production, the software must still go through external compliance scans. One example of this is found in web applications that capture credit card information as part of a financial transaction. Credit card merchants are now required to have their applications go through a Payment Card Industry (PCI) compliance scan by an independent, external provider. If one of these external compliance scans is required for an application before it can go to production, then the initiation and execution of such scans also should be automated as much as possible. We know of one company with a PCI compliance scanning requirement who is integrating HP Fortify (security) checks into their ongoing builds so that the developers are notified as early as possible about possible security issues. It is not yet clear to the team whether a full HP Fortify scan can be done in less than three or four days so this can be a real bottleneck to rapid deployments. If more rapid deployments are required, there has to be a discussion with the external compliance verification agency of whether PCI compliance can be maintained with only a subset of a full scan.
“One-Click” Deployment – While not achievable in many organizations due to regulatory or policy restrictions, in the ideal world, teams would have the ability to select a software build for deployment to production and with the click of a mouse promote the software. Executing typical governance functions such as user acceptance testing, independent systems integration testing, and scheduled deployment windows all slows down the release of software to production, often forcing days – or even weeks – into the timeline between code completion and live deployment. For truly continuous deployment, teams need to be able to bypass these quality assurance and management processes. Obviously, this requires very high-quality code to consistently come out of the development phase – something many organizations have difficulty achieving.
Automated Database Migrations – Data schema changes may occur during an agile development project. Such changes complicate deploying code to production as database updates also need to be coordinated. In continuous deployment environments, these changes need to be automated. Automated database migration is a concept that became popular through Ruby On Rails several years ago and is now implemented in a wide range of languages such as SQL, Java, or C#. Migrations are typically written in pairs: one to modify the database forward and one to roll back the same change in case of mistakes. A typical project will have a database in several environments that all use the same schema (for example: Development, Staging, UAT, and Production) and automated migration ensures that they are all consistent and reproducible.
Automated Software Alerts and Monitoring – If code and database changes are being deployed at the click of a button, one should monitor the solution closely once it has been deployed to a production environment. Code should be written with monitoring “hooks” for application monitoring tools such as IBM Tivoli Monitoring, HP Application Performance Management, or even Open Source tools such as the Nagios package. Software applications should generate alerts that these monitoring tools can access to identify errors at a granular level. In a perfect world, these monitoring tools would not be necessary as we should be generating perfect, high-quality code from our development phase; however, in the real world, these tools become a necessity. Because extensive (and time-consuming) independent testing has not occurred at the end of the development phase, teams attempting continuous deployment need a way to identify granular issues in real time and monitoring tools are an ideal solution to this problem.
Flags to Enable or Disable Features – Finally, once we automatically deploy software with the click of a button, and our automated monitoring tools sense a problem, we need a way to at least disable the offending features and at most quickly revert code back to a previous version. Externalizing flags to enable or disable features is a simple programming technique that can allow monitoring tools (or administrators) to turn off troublesome areas quickly, keeping a production environment running while the problem is investigated and fixed in a development environment. This also allows us to deploy an incomplete feature into a production environment; with the flag for the incomplete feature turned off, no one will ever see the feature and the code will not execute. Having the ability to do this means that software can be promoted to production at any time, not just when features are complete. Similar to feature flags is the concept mentioned earlier of backing out database schema changes if they are found to cause problems. Development managers must take care in maintaining traceability between code changes and data schema changes so that related items can be turned off or rolled back in parallel to avoid causing further issues.

All of these prerequisites mean that continuous deployment is very difficult to achieve and to execute well. It is not just a fancy term for debugging code in the production environment – which, although unfortunately common, is clearly a very bad practice. Continuous deployment requires clearly-defined standards, very strict discipline among team members, a high level of skill, a maniacal focus on quality, and unwavering professionalism. In short, it is achievable for mature agile development teams but is certainly out of reach for those new to agile development practices.

Many companies have been able to achieve this gold standard of agile development:

Etsy, an online marketplace for handmade items, deploys code to production an average of 50 times per day. In order for such a large number of daily production deployments to succeed, their code quality is forced to be exceptionally high.
Facebook has institutionalized continuous code deployment with no explicit human governance checkpoints. They have incorporated extensive application monitoring, however, to identify when they have introduced an error. Facebook mandates that its developers create automatic rollbacks to address any errors. In some cases, the error-handling routines in the Facebook source code turn off offending features, creating a self-modifying code base.
Finally, most impressive of all, Google has an amazing continuous build system that runs 75 million automated regression tests per day across their codebase. Google has taken automation to the extreme to manage their 5,500 source code check-ins per day.

As we have shown, faster releases to production are possible. What business sponsors must realize, however, is that to continuously deploy code requires a number of development environment, application design, production monitoring, coding practice prerequisites. While those may seem simple to achieve, the agile process maturity, high level of team discipline, and extreme focus on quality may be harder to achieve. Organizations should start with obtaining some of the agile benefits that are easier to achieve and leave continuous deployment – faster delivery – for later when they have achieved increased maturity.

Kevin Aguanno is a principal consultant with GenXus Management Consulting, a specialist in project and programme management strategy consulting with deep expertise in agile delivery frameworks. Author of over 20 books, audiobooks, and DVDs on agile topics, Aguanno teaches agile methods at several universities and at conferences around the world. Find out more at www.GenXus.com/aguanno.

Mike Bowler is an experienced agile consultant and coach with a strong emphasis on both process and technical practices. He is known in the agile community for his strong technical skills such as Test Driven Development (TDD), refactoring, pair programming, and continuous delivery. He regularly coaches teams on the use of these skills using languages such as Java, Ruby and C#. Find out more at www.GenXus.com/bowler.

Agile Methods and the Need for Speed

When asking people why they want to use agile delivery methods, one of the most common reasons I hear is that they want to “deliver faster.” It seems that there is a widespread frustration with the way administrative bureaucracy, inefficient development processes, and overburdening governance processes impede project performance. In many cases, an apparently simple, short development project cannot be delivered quickly because of the process and governance overheads that stretch the project out across the calendar and act as a multiplier on the estimated project budget.

Of course project sponsors are frustrated with this situation – I’d be frustrated too. If there is needless red tape slowing down a project, that is an evil that should be rooted out and eradicated within our organizations. The problem, however, is that agile methods are not about delivering faster; rather, their benefits are in other areas:

Lower Risk of Building the Wrong Thing — With frequent demonstrations of the evolving solution, the project sponsor and other stakeholders can see where the project is headed and they can redirect the project team’s efforts if there has been a misunderstanding of requirements. Additionally, this redirection can include the addition of new requirements or changes to existing requirements to ensure the project is delivering optimum value. It is important to note that the business stakeholders’ understanding of what they asked for evolves over the course of the project, bringing new insights and new requests.
Rapid Reduction in Technical Risk — Through careful prioritization, the project team can quickly eliminate technical risk in the project by validating the solution design in early iterations. If an assumption proves wrong, or if the solution design does not work, then there will be minimal rework required (and possibly plenty of time remaining on the schedule) to correct the issue. Once the major technical issues have been resolved, the remainder of the project should proceed without further major interruptions.
Higher Quality — By testing throughout the project, defects are found early when there is time left in the project to correct them and relatively low level of rework required to correct the problems. This is very different from the waterfall method wherein testing is performed at the end of the whole project, leaving little time left for correcting issues and a higher likelihood that corrections will require significant updates across many areas of the completed solution. Add in the benefits of regression testing – retesting past features/deliverables to ensure that recent changes or additions have not impacted them – and we can see that our most important items are tested and then retested over and over to ensure that they are of the highest quality at the end of the project.
Reduced Waste — Agile methods put a very strong emphasis on continuous improvement activities with an aim to improve efficiency of the delivery process, allowing teams to reduce waste. At the end of each iteration, the delivery team holds a retrospective — a “lessons learned” meeting – where team members identify processes that are working effectively, those that did not work well, and what changes can be recommended for the next iteration to improve the teams’ productivity and the quality of its deliverables.
Improved Trust — Under the agile delivery model, a project team makes smaller, short-term commitments that are easier to estimate and to achieve. As a result, the team develops a reputation for meeting their commitments, which helps build trust with the business sponsor.
Open, Transparent Communications — Agile methods recommend frequent, open communications between team members and also between the project delivery team and the project sponsor. Daily team meetings help team members understand each other’s issues, fostering collaboration, mentoring, and early identification of issues to the project manager for resolution or escalation. Daily access to the project sponsor helps with escalation and rapid decision making. Agile status tracking techniques, such as requiring the delivery team to demonstrate completed deliverables at the end of each iteration, also help to improve transparency by revealing the true progress of the project — there should be no last-minute surprises for the sponsor of an agile project.
Improved Morale — With a team able to meet its commitments by delivering completed solution components on a regular basis, the team members feel productive. Combined with the positive results of continuous improvement activities, team members know they are being efficient and see the value they are creating for the business. Shared team goals lead to cross-functional cooperation, which also adds to team productivity. All of these lead to good morale among team members.
Lower Risk of Being Late or Over Budget — The above benefits combine to reduce the risk of the project completing late or over budget. Frequent feedback cycles ensure that misunderstandings are surfaced earlier when there may still be time to correct them without impacting the timeline. Continuous testing finds defects earlier to that they may be fixed earlier, reducing the risk of a major defect being found in the last days of the project. Continuous improvement activities (retrospectives) ensure that the project focuses on delivering efficiently. Transparent communications help to reduce misunderstandings that may lead to rework or other project delays. As you can see, many of our agile practices contribute towards reducing the risk of the project exceeding schedule and budget constraints.

The above items are the most common (and substantial) benefits that organizations achieve through the use of agile methods and none of them related to speed. There are a couple of other benefits, however, that do tie in to the need for faster delivery:

Earlier Delivery of Business Value — By breaking the project down into segments that are delivered incrementally in regular intervals, the project creates the opportunity for the sponsor to make some use of a completed portion of the solution partway through the project. The sponsor may decide to use the partially-completed-but-still-functioning solution to beat competitors to the market and capture valuable market share, demonstrate to business partners what will be forthcoming when the project is complete so that they can begin aligning their own business offerings with the new solution, begin training users of the solution before the entire solution is complete, or any number of other beneficial scenarios. To capture early benefits in this way, the project sponsor needs to carefully prioritize project requirements and work with the project team to build a release plan that aligns with the business’ strategy. Each release to a production state requires a significant investment in acceptance testing, independent quality assurance, data migration, training support staff, and other production-readiness activities. Business sponsors should carefully consider these activities and costs when determining how often they should promote work-in-progress into production, as too frequent promotions can negatively impact the business case.
Possibility of Completing the Project Early — Something that rarely happens under the waterfall method but which becomes feasible using an agile approach is the early completion of the project, saving significant time and money. If a waterfall project is terminated three quarters of the way through, the project team is probably still building the solution or is just entering the testing phase. At this point, the solution is untested and likely has many defects preventing its use by the project sponsor to achieve the expected business value. With the delivery of the solution in fully-completed segments throughout the project, with the ordering of those segments in order of business priority, and with early and continuous testing, there is the opportunity with agile methods for the business to decide to end the project early, when the remaining work is of lower priority not being worth the extra investment to build those pieces.

These last two items, when implemented, can lead to faster delivery. Project sponsors should be very conscious, however, that the early promotion of a partial solution to production incurs significant extra costs for acceptance, production readiness verification, and other transition activities. The option to end the project early also comes with the cost of cutting out some of the lower-priority project scope.

In both of these cases, increased speed of delivery comes with a significant cost that needs to be carefully considered. Sponsors citing “the need for speed” as their primary reason for pushing for an agile approach may not understand the other benefits that may be easier to obtain and may more meaningfully impact their bottom line. Single-mindedly pushing for speed may jeopardize the attainment of the project business case without a sound understanding of the activities required to transition deliverables into a production state. Project sponsors should engage in broader discussions with the delivery team to understand the required transition activities and to prepare a delivery strategy that maximizes the delivery of business value considering all relevant costs. As always, increased communication is vital for project success.

Kevin Aguanno, PMP, MAPM, IPMA-B, Cert.APM, CSM, CSP is a principal consultant with GenXus Management Consulting, a specialist in project and programme management strategy consulting with deep expertise in agile delivery frameworks. Author of over 20 books, audiobooks, and DVDs on agile topics, Aguanno teaches agile methods at several universities and at conferences around the world. Find out more at www.AgilePM.com.

What's New in Agile Project Management Certifications

An article comparing the new PMI agile certification to the other agile PM certifications in the marketplace.

There’s lots of buzz in both the project management and agile communities recently with the announcement from PMI that they are launching a new agile certification. Questions abound: what are the PMI agile certification requirements, how does this compare to the Certified ScrumMaster (CSM) or Certified Agile Project Manager (Cert.APM) qualifications, when can I apply, and many more.

PMI has provided some guidance on the process and requirements, but much is still currently unannounced as they are finalizing the details. A pilot certification round is starting imminently with a full rollout this summer – the exam should be fully available through Prometric Testing Centres in September 2011 with the application process starting in May or June. In the mean time, Internet discussion boards and chat rooms are filled with speculation.

What we do know for sure is that to become certified, you’ll need to pass a 3-hour multiple-choice exam on agile management with 120 questions, of which only 100 will count towards your score – the other 20 are experimental questions being considered for future exams. The exams will be available via computer or paper at Prometric Testing Centres, the same as the PMP or other PMI exams.

For educational requirements, you’ll need to complete a minimum of 21 hours of agile-specific training in addition to having a basic high-school diploma (at a minimum). So, if you are CSM who has just completed the basic 2-day Certified Scrum Master course, you’ll need to go out and get an additional day of training. This is probably a wise thing to do anyway, as the exam will cover a lot more than just Scrum practices. For example, the sample questions that PMI has on their web site includes questions from Extreme Programming (XP) and Scrum, plus many questions that are outside the scope of pure Scrum, such as the construction of release plans.

There are also experiential requirements. A candidate must demonstrate 2,000 hours of working on project teams in the last five years (not necessarily as the project manager – just working in a project environment), plus 1,500 hours of working on agile projects in the past two years. PMPs will skip the 2,000 hour requirement, but must still meet the 1,500 hour requirement. This agile experience presents a significant hurdle that will prevent many people (including new CSMs) from earning the PMI certification. It is not just a test of agile knowledge, but rather you’ll need to demonstrate experience as well.

How does this stack up against the other agile certifications? Take a look at the table below:

	Agile PM Certifications
	Certified ScrumMaster (CSM)	Certified Agile Project Manager (Cert.APM)	PMI Agile Certification (name still to be finalized)
Minimum Education	None	None	High School
Mandatory Minimum Agile Training	2-day CSM course	3-day PMAC-accredited agile PM course	21 hours of agile training
Minimum Project Experience	None	1 year as project manager	2,000 hours in last 5 years as project team member
Minimum Agile Experience	None	None	1,500 hours in last 2 years as agile project team member
Exam Length	25 multiple-choice questions in 1 hour	40 multiple-choice questions in 2 hours	120 multiple-choice questions in 3 hours
Passing Mark	Not applicable – everyone who writes the exam earns their CSM regardless of score	70%	Has not been announced
Certification Fee	$50 (usually included in mandatory course cost)	$100 (usually included in mandatory course cost)	$495 (computer-based test) or $445 (paper-based test) $60 discount for PMI members
Certification Validity Period	1 year	For as long as holder is a member of PMAC	3 years
Recertification Cost	$75	Not applicable (Membership varies from $25 to $100 per year)	$130 plus 30 additional hours (PDUs) of agile-specific training

Initial observations show that the Certified ScrumMaster credential is not on par with the other two certifications. Not only does it have low-to-nonexistent educational and experiential requirements, but its exam is not credible if everyone who attempts the exam gets their Certified ScrumMaster designation even if they don’t pass the exam. The CSM credential is offered by the Scrum Alliance. They state right on their own web site: “Once you have completed the evaluation you will be granted Certified ScrumMaster status regardless of your score. If you score poorly, however, you will receive feedback detailing where you are deficient and what resources you should study to improve.” The CSM certification was criticized in the past for not having an exam at all – this new approach does not make much of a difference if you get the certification even if you fail. On the strength of this last point alone, those interested in agile certification should focus on the other two options.

Overall, the new PMI agile certification compares favourably with PMAC’s Certified Agile Project Manager. Both require 3 days of agile-specific training, both require about a year of project experience, and both have a multiple choice exam (though PMI’s is longer). The key differences: PMI’s exam requires agile project experience (which may exclude many potential candidates) and it is much more costly to obtain (almost five times more expensive) and more costly to maintain. Still, with the marketing might of PMI behind the exam, it should quickly catch on.

Those interested in obtaining agile project management certification should put acquiring the new PMI agile credential on their long-term career development plan. In the short term, the Certified Agile Project Manager credential from PMAC is a great interim step.

One should not forget the Certified Senior Agile Project Manager (Sr.APM) credential from the Project Management Association of Canada that was launched this year. It takes an even more rigorous assessment approach than either of the three certifications mentioned above. For this more advanced certification, candidates need to prove that they have competently managed agile projects in the past. To assess the competence of the candidates, the PMAC looks for:

understanding of agile practices as evidenced by obtaining the Cert.APM qualification
feedback from team members to see if the candidate can effectively lead a team
feedback from sponsors to see if the candidate can manage stakeholder relationships effectively
evidence of sound agile practice through the presentation of agile project artifacts (release plans, backlogs, burndown charts, etc.)
a detailed project report describing how specific agile practices were applied on a sample project, and
demonstration of the necessary soft skills through a face-to-face interview.

With all of these elements, it is clear that this last certification is more costly and time-consuming to achieve. However, it is clear that the Certified Senior Agile Project Manager credential is the gold standard of agile project management certifications.

Kevin Aguanno is a Certified Executive Project Manager with over 20 years of experience. He specializes both in recovering troubled software development and systems integration projects and in helping companies through the agile adoption process. He is the author of over 20 books, DVDs and audio CDs on project management and agile-related topics. For more information, visit www.AgilePM.com

Project Management Advice from Popular Music

An article taking project management advice from pop songs.

I was sitting in a project team meeting yesterday where a group of us were trying to figure out the right strategy for dealing with a difficult project sponsor. The issue was that the scope of the project was constantly changing and we were being rebuffed by the sponsor when we tried to point out that our requirements gathering and analysis budget was already spent, yet new requirements were popping up daily. The sponsor was saying that they need all of their requirements documented and the impacts on the solution design analyzed – which is correct; however, the sponsor is not willing to reallocate funds from the solution build budget to the requirements budget, nor is he willing to discuss adding funds to the project overall budget.

To make matters even more difficult, the last time we approached the sponsor to make him aware of the impact of this ongoing requirements churn on the project budget and timeline, he escalated to our sales team to complain that we were upsetting him and not doing our proper jobs by managing the project within its constraints. The sales team members in our meeting (who own the overall customer relationship) were insisting that we find a way of continuing the work without highlighting the budget issues. In essence, they were arguing that we should hide the fact that we are going to use up so much of the overall project budget during this requirements churn that there may not be enough left to build a viable solution. They were telling us not to speak with the sponsor further on this issue.

While this was going on, I heard the chorus of a song by Des’ree running through my head:

You gotta be bad, you gotta be bold
You gotta be wiser, you gotta be hard
You gotta be tough, you gotta be stronger
You gotta be cool, you gotta be calm
You gotta stay together…

I was immediately struck by how these lyrics could have been written for a project manager.

Being strong and tough while still keeping a calm and cool demeanor would be very useful in our situation. We needed to stand up to the salespeople while not seeming to be unreasonable and too confrontational or difficult to deal with.

So, I took a deep breath, gathered my courage (was bold), and I started to push back (was tough). I used logic (wisdom) to highlight the negative outcome of their approach. I did not let their numerous interruptions and attempts to redirect the conversation divert me from explaining my position (was strong), and did all of this in a calm, level-headed (cool) manner. Basically, I followed the advice of the song.

The delivery team was behind me and soon heads were nodding and supportive comments were coming from all members of the group. They saw what I saw and were equally concerned about getting the project back on track. All they needed was someone to follow, someone to stand up and lead them into confronting the dysfunctional approach promoted by the salespeople.

The more astute of the two salespersons quickly dropped his argument when he saw that the majority were behind me and that my arguments held up against their objections. He eventually sided with reason and good practice. The other salesperson continued to push his own dysfunctional approach for a while until he realized that he was the only holdout in the room. At that point, he quickly changed his approach to match ours, but tried to make it look like our approach was his idea all along. I wasn’t concerned about who got the credit for the idea – my self-esteem didn’t need the ego boost – so I let him save face by claiming credit in front of the group. (It really didn’t matter, since they all saw how things had unfolded; he wasn’t fooling anyone but himself.)

In the end, if all worked out. The salespeople agreed to the approach that the team had initially proposed. They agreed to meet with the sponsor and explain that the requirements churn on the project was consuming solution development funding and that he needed to be aware of this. They agreed to propose that the project pause for a while until the sponsor can decide what to do about all of the changes being proposed by the various involved stakeholders – after all, the budget can only accommodate a small fraction of the work required to build a solution meeting all of the newly-emerging requirements. And they are going to get the sponsor to formally sign off on a re-allocation of funding or additional funding before the project resumes.

I guess it pays to be bad, bold, wiser, hard, tough, stronger, cool, calm and together.

Kevin Aguanno is an executive project manager specializing in providing project strategy consulting services, especially around agile approaches and troubled project recovery. He is an award-winning speaker and the author of over 20 books, audiobooks, and DVDs on project management-related topics. Find out more at www.AgilePM.com.

Testing Strategy is Critical for Project Success

I once heard the president of a large company say that sales people were important because they increased the revenues of the company but that project managers were more important because they turned those revenues into profits. And those profits, he noted, drive an increased share price (the value of the company in the marketplace).

If we as project managers are responsible for the creation of a company’s value, then we have a professional obligation to perform that job well, as the converse would also be true: project managers performing poorly can also destroy a company’s value. How do we perform our job well? To answer this, we need to look at which project management activities have the greatest impact on achieving the project’s desired outcome, as valued in the business case.

I personally believe that the two most critical contributors to achieving project business case outcomes appear at the start and end of our project lifecycles: good requirements analysis, and the strategic application of testing activities. The two of these combined ensure that the project is focusing on creating the right outcomes and that the project is verifying or demonstrating that the outcomes have been achieved to ensure the delivery of optimal business value.

The key concept here is “optimization.” Yes, many project activities drive value. Some, however, have an incommensurate effect on the total business value delivered by the project when it is completed. By conducting a Pareto analysis of the most common project activities, we see that creating the right outcomes (proper requirements analysis) and ensuring that those outcomes are achieved (proper testing) have the highest business value to effort ratio.

Of the two, I believe that testing gives you the biggest lever. Yes, proper requirements are important, but typically requirements-related activities are only a small portion of the overall project activities and happen at the beginning of a project when everyone – including the business people involved – understand the project environment the least. Testing, however, happens mostly near the end of a project where there is much less uncertainty about what are the desired project outcomes. Testing activities (and the related defect correction efforts) are what determines whether or not the project has been successful. If inadequate testing is performed, then the outcomes created earlier in the project will not drive the proper (or possibly any) business value. Quality assurance (testing) is one of the most critical activities for achieving project success.

Similar to under-testing, there is a danger of too much testing, too. We need to find the balance between additional testing and the delivery of an equal (or greater) proportion of business value. At some point during the testing process, additional testing effort will not create enough additional business value to justify the extra expense. A strategic approach to testing needs to be considered by the project manager when creating the initial project approach.

Here is where another Pareto analysis may come in handy. Consider all of the types of testing that we can perform on a project: usability testing, accessibility testing, performance testing (including load and scalability), functional and systems integration testing, disaster recovery testing, etc. – on an individual project, some of these will drive more value than others. We need to consider the business case behind the project to know which types of testing will drive the most business value. For example, perhaps a given project requires rock-solid 24x7 performance or else the business will suffer; in that case, disaster recovery testing may drive a measurable amount of business value, while it may add little value in other, less mission-critical projects. We cannot take the same testing approach on every project – we absolutely need to tailor our testing activities to the individual needs of each project’s business case. In other words, it is essential that we consider testing strategy when we begin planning our project.

So, when that company president said that it was project management that drove business value, I believe that if we had the chance to dig a little deeper discuss what was underlying that comment we would have heard that the project manager’s responsibility for project value includes building the right things and then verifying that those things meet the business case needs. And a disciplined focus on testing strategy will ensure that the project has created the planned business value, with the right test strategy ensuring that these validation activities have been performed in an optimal manner.

Kevin Aguanno is a Certified Executive Project Manager with deep expertise in recovering troubled application development and systems integration projects. He is the author of over 20 books, audiobooks, and DVDs on PM-related topics including the upcoming book “Insider Tips for Agile Test Management.” Find out more about him at www.AgilePM.com

My Project Management New Year Resolution

An article on project management personality types and how they affect our New Year resolutions.

As it is January, I thought it would be a good time to share with you my project management New Year resolution. But before I share it with you, I want to share an observation: if I could make up my own personality categorization system for project managers, I might say that there are two main types: builders and maintainers.

Builders are the project managers who love to manage projects that create brand new things: shopping malls, online courses, software applications, new products, etc. They are excited by the unexpected challenges they will face and thrive on the creative energy generated by the team.

Maintainers are those project managers who prefer projects where there are fewer “unknowns” and perhaps an overall lower risk profile. These are projects updating, renovating, or maintaining existing products, buildings or systems rather than creating new ones. These project managers focus on optimization and efficiency as their main goal.

I would imagine that the New Year resolutions of these two types of project managers would be very different. New Year resolutions tend to say that we will begin exhibiting some positive behaviour that we probably should be doing now but aren’t, or that we will stop a negative behaviour. Builders (who are more interested in tackling challenges like project issues than in standard administrative processes) may have a resolution saying “This year, I will begin updating my project financial tracking spreadsheet weekly instead of monthly, just before the deadline.” Maintainers (who tend to be more interested in using metrics to optimize the project process than in dealing with broadly-defined but imprecise strategic directives) may have a resolution saying “I will take the time to perform a formal stakeholder analysis at the start of all of my new projects, and will use this information when I craft the project approach.”

Now, let’s be practical. I know that we should probably be doing all of these things all the time; however, in the face of day-to-day project pressures, and the common problem of not having enough hours in a work day, we have to let something slip. What that may be depends upon our organization (what they measure), our project (what our customer wants), our team (how much direction they need), and our own personality (Builder or Maintainer). The situation is not as simple as I may have made it sound above; however, I think that a project manager’s personality does have a strong influence on his or her choice of a project management New Year resolution.

My resolution: to spend more time following up on action items assigned to team members. I expect that, since we spend so much time trying to hire the right people for our organizations, that we have a pool of reasonably skilled, competent, and motivated people from which to draw our project teams. I expect that people will keep their commitments, never lie, and generally try to cooperate with others on the team. Basically, I expect everyone to act as professionally as I do myself. Maybe this is a little too naïve – I have had a few disappointments over the years where others fail to live up to my standard – but I believe that most people mean well and will try to do their best.

My resolution will help me avoid some future disappointments by identifying those who are not meeting their commitments early on so that I can take action to avoid any major issues occurring. It is easier to fix problems while they are still small ones rather than avoid them until it is too late to resolve them.

Based on my resolution, I am sure that you can guess my own project management personality type. I am a Builder. That means that I like dealing with “fuzzy” situations, project strategy, stakeholder relations, and project issues but I am less excited about the administrative side of my job: issuing status reports, reviewing time sheets, financial tracking, sending out meeting minutes, etc. Yes, I do these tasks, but to me they seem like chores – not something I look forward to doing, and a candidate for procrastination in preference for more exciting project challenges.

This year, I plan on focusing a bit more on the administrative side of my job. I must find a way to make these activities seem fun. Maybe I can “psych” myself up to looking forward to these activities. Maybe I can repeat a mantra ten times each morning: “I can’t wait to start working on this week’s status report!” No, I don’t think this is working for me. I guess I’ll just have to bear with it and force myself to do the work. No one said project management was all fun.

Kevin Aguanno is an executive project manager whose competence is certified by IBM and the International Project Management Association. He is also PMP-certified by PMI. He is currently the President of the Project Management Association of Canada and assesses project management competence for IPMA associations in Canada and the USA. More details and contact information can be found at www.AgilePM.com.

Project Startup Activities are Key to Success in Both Agile and Traditional Approaches

A new article on the importance of project startup activities on agile projects.

I recently attended the Business Analyst World conference in Ottawa, Canada. The audience was comprised of mostly (no surprise here) business analysts but also included project managers, technical leads, and a few project sponsors. What I found intriguing was that about one third of the track sessions were concerned with agile-related topics, and the buzz in the hallways between sessions and at lunch seemed to lean towards agile. I guess this means that agile is now solidly on the radar of the mainstream project community.

Having delivered a presentation and participating in a panel discussion on agile, many came to me during the lunch sessions and breaks to answer questions they had about the implementation of agile methods on real projects. A theme that commonly emerged was the chaos that project teams were facing in the face of inadequate project startup activities. Some believed that project startup work was essential to traditional (a.k.a. “waterfall”) approaches, while these activities were not required for agile approaches. Let me summarize for you the answer I shared over and over again during these discussions.

First off, for there even to be a project in the first place, some up front work needs to take place. For executives to approve the expenditure of resources on a project, they want to know three things: what are they going to get, for how much money, and when will it be delivered – the old iron triangle of scope, time, and budget. Typical governance policies in organizations will not allow a project to begin without appropriate approval, and those providing such approvals require this basic information to make their Yes/No decisions. Such decisions are usually based on some type of business case analysis. The level of rigor in developing the business case depends upon the size of the project, the organization’s industry, and its level of maturity. Generally speaking, however, the business cases should quantify the benefits expected from a project and the costs required to create the environment wherein those benefits can be realized. Using that information, a business executive can then decide if the project is “worth it” – i.e. do the benefits outweigh the costs enough to justify the risk and investment in the project. The work required to gather information on benefits and costs is required no matter which project delivery method is being used: traditional or agile. This information is needed to decide whether or not the organization should bother launching the project (traditional or agile) at all.

Developing the benefits analysis for a business case is one piece of work that I won’t go into detail here. The process is the same whether one is using a traditional or agile approach. Developing the cost case, however, differs somewhat.

A cost case is developed by gathering the prices of materials and labour inputs to the project. Labour input estimates from external vendors are usually provided in dollars, and internal service teams may provide their estimates in either dollars or hours/days. Regardless of whether these estimates are coming from internal or external service providers, think for a moment on what work is required to create them. In both cases, the underlying number is an effort estimate measured in hours or days. External vendors will then apply contingencies and multiply this by some type of cost rate in dollars. Effort estimates can then be translated into a project schedule/timeline. To come up with the effort estimate, however, requires a much deeper analysis.

A team being asked to estimate the effort to do some work first needs to understand the nature of the work (overall solution design or approach) and enough details (scope or estimating assumptions) about the work that they have a reasonable basis upon which to base their estimates. It is clear then that before estimates can be prepared, some amount of solution design work must be done; else, how will the team be able to prepare their estimates – they would not know what it is that they are being asked to estimate.

The overall solution design, in turn, is based on an even earlier analysis of requirements. We need to understand the business requirements that are driving the need for the project’s output in order to make sure that we understand all of the required aspects of the solution. These requirements can then be transformed in the context of an overall solution design into a list of solution features for which the project delivery team can then provide estimates.

Under most organizational governance models, all of this work is required to be completed before a project can begin. This work all leads to the completion of a business case that the project funding person or group within an organization needs in order to conduct a reasonable assessment and make its Yes/No decision on whether or not to proceed with the project.

The difference between traditional and agile methods is the level of detail that goes in to the preparation of the business case. Because traditional methods perform most of its analysis and design work up front in order to come up with a detailed project implementation plan, these methods need to spend a lot of time conducting detailed analysis in order to prepare a detailed business case. Agile methods differ in that they begin with only a high-level understanding of requirements and solution design before the team prepares rough estimates that can be put into an initial business case. Initial funding may begin with only a high level business case, but typically the detailed business case is required before the full project funding can be released. In traditional approaches, the detailed work is usually completed before developing the project solution can begin, while under agile approaches, the solution development work can begin right away and the more accurate estimates and plan are delivered after a prototype/proof of concept phase wherein the delivery team gains experience with the technology, the other team members, and the stakeholders before committing to a more firm set of effort estimates and timeline.

With the greater level of detail required, traditional approaches tend to spend more resources in preparing business cases for the Yes/No funding decision. Agile methods tend to work at a higher level of detail, avoiding deep analysis until just before the work on an element of the solution begins. This means that the organization can get to a Yes/No decision much more quickly and cheaply using agile methods. Yet, it is important to point out that a business case for an agile project still needs up-front requirements analysis and solution design, just at a higher level of detail.

Adequate performance on these project startup activities of requirements analysis, solution design, estimating and planning can mean the difference between success and failure on your project – regardless which delivery method (traditional or agile) that you use. If you are using traditional methods and do a poor job on your project startup activities, your estimates and plans will be wrong and your project will struggle right from the moment that real project begins. Similarly, and agile project that does not spend adequate time with up-front work (before the first solution development iteration) will not only have a difficult time getting funding approved, but also the team will struggle in trying to build the right solution and in providing meaningful tracking and forecast metrics to help manage the project delivery.

Many agile proponents minimize the importance of project startup activities to the overall success of the project. In part, this is due to the fear that teams will be tempted to do a full, detailed up-front requirements analysis and solution design, wasting resources on items that may change before they get implemented later in the project. In other words, they are afraid that teams will migrate back towards doing a big design up front (BDUF) – a less than agile approach. As a consequence of this, many inexperienced agile project leaders then try to launch projects without adequately performing the project startup activities, leading to failing or troubled projects and demoralized teams. Many organizations have attempted and failed at their adoption of agile methods for this very reason.

It is absolutely critical that our project leaders understand the differences in the level of detail required in traditional and agile approaches and to ensure that they expend the right amount of effort in these project startup activities. Failure to do so means that your project may not only be significantly challenged throughout its lifecycle but also its business case may never be approved in the first place.

Kevin Aguanno, PMP, MAPM, Cert.APM is an executive project manager for the world’s largest IT services organization and is its Canadian Agile Centre of Competence lead. He has written over 20 books, DVDs, and audiobooks on agile and project management-related topics. Find out more at www.AgilePM.com

Why Project Managers Should Master the Art of Bribery

A new article by Kevin Aguanno.

In most countries around the world, bribery – the payment of secret funds to someone to get them to bypass standard processes or to alter their standard behaviour – is considered immoral and often illegal. The codes of conduct or codes of ethics from many of our professional organizations explicitly forbid bribery. So, for the vast majority of project managers, bribery is out of the question.

Let me share a story with you, however, that may sway your opinion a bit. One day about 3-4 months ago, I was discussing a foreign project management training assignment with a colleague. He was being asked to teach a 3-day project management course in a far-off country. (For the sake of not offending anyone, let’s leave the country name out of this as it is not necessary to make my point.)

While discussing the contents to be covered by this project management course, the foreign contact asked about training around “individual performance incentives.” My colleague initially took this to mean standard rewards and recognition discussions that fall under the general category of leadership and motivation. Upon further discussion, however, it emerged that what was really needed was a course module on the effective use of bribery.

Understandably, my colleague was shocked at this request and did not know how to address it – thus, his conversation with me, seeking my thoughts on the matter. After we had discussed the issue at length, what started as a black and white issue (bribery is always wrong, therefore he should not teach the course module) became one nuanced with shades of grey (maybe it was allowable in certain, restricted, circumstances). Let me share with you the key points that led to the revelation.

In Western Europe, North America, and many other places around the world, bribery is illegal and should not be condoned under any circumstances. In many other parts of the world, however, bribery is a fact of life. In fact, in some countries, to get a project done on time and on schedule requires the effective use of bribery – including knowing how much to give (and under what circumstances) to elicit the most effective performance. This could range from paying “tips” to customs agents to get your critical, imported parts released quickly for delivery to your job site to paying a “bonus” to subcontractors to have them move their work on your project to the top of their to-do list.

I am NOT talking about outright corruption such as paying government officials to award you contracts that you would not have otherwise won fairly or paying inspectors to “look the other way” when doing a job site safety assessment. I think most would agree that these situations cross a very clear moral line – one creating unfairness in a process and the other leading to safety issues that may even endanger people’s lives.

Rather, I am highlighting situations where work will still get done (eventually) but where an added motivation (via a valued item or service) could affect the prioritization of the work and improve its schedule; for example, incenting a contractor to add additional workers to your project (perhaps by pulling them off of other projects) to speed up your timeline to help you make a critical date. You would not be “paying” someone to perform work they would not otherwise be doing, or to bypass governance regulations, but rather providing them performance incentives that may motivate them to improve their delivery on your project.

In our normal business interactions, we often provide such incentives to others: U.S.A. government contracts sometimes include incentive payments for early project completion, and auto manufacturers sometimes provide added bonuses to their suppliers if the quality of supplied parts exceeds a minimum threshold. I’ve even supplied coffee and pastries to those who come to my meeting on time – by not providing enough for everyone, it encourages people to come early to guarantee that they will get the “free” treat. By doing this consistently, it corrected a problem with poor meeting attendance. Would we consider any of these last three examples bribery? Of course not. They are commonly-accepted uses of what I call “individual performance incentives.”

Extending this out to the larger project environment, the incentives that we commonly provide to companies (such as auto parts suppliers) could also be provided to individuals. This should be fine as long as health/safety, legal, or governance regulations are not being violated, as discussed earlier. This is a nuanced area to be navigating, for sure, but one that most people should be able to work through without turning to corruption. Many are concerned about letting people navigate these moral grey areas, as some people will succumb to the temptation to slip over to “the dark side” and participate in corruption. Yet, there is much value that can be gained by using these individual performance incentives correctly.

In many parts of the world, these incentives are a part of daily life. Almost nothing gets done quickly without “greasing the wheels” with cash or other incentives. In these countries, I would support the idea that project management training should include information on how to do this efficiently and effectively without crossing the line into corrupting officials or endangering lives. I believe that our outright opposition to bribery needs to be adjusted to accept a clearer definition of bribery – one that specifically exempts individual performance incentives – with a focus on maintaining safety, health, fairness, and proper governance.

Kevin Aguanno, PMP, IPMA-B, MAPM is an executive project manager with experience across multiple industries, managing both IT and construction projects. He is well-known for his expertise in agile project management and recovering troubled software development and systems integration projects. He is the author of over 20 books, DVDs and audiobooks on project management-related topics and teaches PM classes as a guest lecturer at several universities. More on Aguanno's work can be found at www.AgilePM.com.

Project Management and Office Politics

An article describing the difference between transactional and strategic project managers and how the latter uses office politics to optimize project success.

I was teaching a project management course last week and presented a module on stakeholder management. In this module, I presented some techniques for identifying project stakeholders, some criteria for evaluating them to see which ones have an important influence over the project, and strategies for dealing with stakeholders who may have some moderate influence over the project but who are not involved in the day-to-day decisions in the project. In all, I thought it was pretty standard material.

What surprised me, however, was a comment from one of the students in the class. He said that he was taught (elsewhere) that the role of the project manager stopped at interfacing with the sponsor — dealing with secondary and tertiary stakeholders was the responsibility of the sponsor, not the project manager. At the time, I thought that this was preposterous — of course a project manager needs to deal with stakeholders other than the sponsor; later, however, I began to think more deeply about this and I came upon a new understanding of the issue.

For argument’s sake, let’s say there are two kinds of project managers: transactional project managers, and strategic project managers. Transactional project managers are focused solely on driving the team to achieve the project scope within project constraints (budget, timelines, etc.). Strategic project managers, on the other hand, focus on finding the optimum path to achieving business value during the project. This second type of manager does still concern themselves about completing the project scope within constraints, but has a different approach that tries to determine what other — hidden — factors may be considered to drive optimum project results.

Transactional project managers are performing standard, basic project management activities. I am not suggesting anything out of the ordinary here.

For strategic project managers, however, I am adding a layer of soft skills and business acumen on top of the basic project management skills to create a more sophisticated, nuanced approach. The International Project Management Association (IPMA) has been setting international standards for project management competency assessments for decades. The organization publishes the International Competence Baseline (ICB) which breaks down the knowledge and experience required by a competent project manager into three areas: PM technical skills (like scheduling, quality management, resource management, etc.), behaviours and traits (like negotiation skills, a results-oriented attitude, creative problem solving, etc.), and general business knowledge (such as programme management, organizational structures, health and safety regulations, etc.). I believe that the strategic project managers have deeper competence in the general business knowledge and display the required behaviours and traits at a deeper level of sophistication. In essence, the strategic project managers are more senior — more competent — than the transactional project managers.

Transactional project managers are given a project scope and some constraints within which to deliver that scope. They would then focus inwards on the core project team to ensure that the team is following a plan that will achieve those objectives. Strategic project managers are different: they focus outwards from the project team and look to the opportunities and threats that exist in the project’s business environment that may impact project results. The strategic project manager would meet with the sponsor and try to find out the details of the business case that led to the project, asking if there were any personal objectives of the sponsor or key stakeholders that the PM could consider when planning the project. After all, there are many paths to achieving project objectives, and some may help the sponsor to achieve other (perhaps covert) objectives along the way. This is where office politics comes in to play.

The project sponsor may have other initiatives that this project could support — perhaps without extra cost — through the way in which it structures its work or deliverables. And while the sponsor has his or her own personal agenda, so do the other project stakeholders. The strategic project manager tries to understand the influence of these stakeholders over the project and the relative importance of keeping these stakeholders happy. Sometimes, the PM will find out that some stakeholders can be safely ignored, or should only be paid lip service to, while others need to be carefully considered and approached with a strategy in mind.

Office politics sometimes can derail a project faster than anything else — by considering the external stakeholders, their power, their (sometimes) hidden agendas, and their level alignment with the project’s objectives, the strategic project manager can structure the project to more likely meet its transactional goals, and to do so while helping other further their own agendas. If he or she can pull this off, the strategic project manager will be seen as a person of influence and a strategic partner for various interests and factions within the business. Which, over time, leads to an even greater involvement in organizational politics. Let the games begin…

Kevin Aguanno is an executive project manager whose competence is certified by IBM and the IPMA. He is an award-winning lecturer for various universities and corporate clients, and is well-known professional speaker. Currently the Vice President of the Project Management Association of Canada, he devotes a lot of his time to supporting the growth of the project management profession. He can be reached via www.AgilePM.com.

My Project is Harder Than Your Project

An article on the comparison of project management complexity between project types.

Over the years that I’ve been attending project management events, I’ve heard project managers from various backgrounds comparing their projects in an effort to see whose project was harder to manage. Typically, these PMs are men – perhaps it is part of the genetic makeup of men that many feel the need to compete with each other to establish some type of social hierarchy.

What I’ve noticed, is that there are two typical results of these comparisons: either both projects are in similar industries and are therefore somewhat comparable, establishing one as clearly larger or more complex than the other; or the two projects are of a completely different nature, with little that can be directly compared. I most commonly see this latter occurrence when one is an engineering or construction project, while the other is an IT project.

When two projects are of a similar nature, we often use budget or team size as a means of comparison. This falls apart when comparing projects of different types; for example, a $10 million software development project is a rather large, complex project of its type but a $10 million expansion to a chemical plant would be a fairly small engineering/construction project. So when an IT project manager brags that he’s managing a $10 million project, the engineering/construction project manager chuckles thinking that the IT project manager must just be a beginner to brag about a project of such a small size. We look at team size in a similar way: an IT project with 70 people on the team and 4 vendors would likely be a fairly-complex project; however, even fairly straight forward construction projects could easily have hundreds of people working on them with dozens of vendors.

This does not mean that construction projects are generally harder to manage than IT projects. We need to look at other factors, since budget and team size seem to be calibrated differently in the two project types. If we look at what is really driving the project management complexity in the different project types, we find that the complexity in managing IT projects comes from the lack of clarity in requirements/scope, while engineering/construction projects are challenged by large numbers of vendors, each with their own unique contract to establish and manage, and the complexities of coordinating the work of so many independent project participants, each worried about meeting the terms of their own contract, not necessarily the needs of the project as a whole.

Requirements and scope in engineering/construction projects tend to be simpler elements to manage. Building codes and other government regulations largely reduce the misinterpretation of requirements by restricting the range of possible options allowed. Also, scope completion is easy to verify (e.g. “Is the foundation done, or not?”). On IT projects, however, scope is typically more challenging to define. The output of a software development project is intangible and many people have a hard time describing the vision of what they want, leading to requirements misunderstandings. Construction projects resolve this issue by using modeling techniques such as sketching elevations (“artists’ concepts”) and creating 3-D models in a CAD package for simulated virtual walk-throughs of the design prior to construction. The modeling techniques used by IT projects tend to create complex diagrams that require special training in UML to be able to understand. Certainly, some of the common IT models will work for you but many of them will just confuse the uninitiated. As a result, an IT project manager will spend a large portion of their management time explaining the project scope to various team members and stakeholders

Vendor and contract management are critical on engineering/construction projects. Even when running a project to design/build a single family home, the project manager will have many, many separate contractors to manage. Continuing our single family home example, the foundation could involve over many contractors: one to survey the site, one to dig the foundation, another to haul away the dirt, a carpenter to frame up the forms for the footings, another to bring in ready-mix concrete to pour into the footings, a company to set up and later strip the forms, another to pour the foundation wall concrete, a building inspection, probably a progress inspection/assessment for the construction finance company. Each of these contractors would have their own unique contract with a scope of work, terms and conditions, and a schedule that would need to be coordinated. One of the main roles of a construction PM is the coordination of these schedules and the coordination of the scope statements to ensure that nothing gets missed or “falls between the cracks.” IT project managers may have vendors on their projects, but typically it is one or two firms even for fairly large, complex projects, so the contract management aspect on IT projects is much diminished.

So, the real underlying argument that should be made to compare two projects of different types should be the comparison of the level of scope clarity with stakeholders versus the number of vendor contracts to manage. This is a more difficult comparison – it is like comparing apples and oranges – and usually leads to a stalemate. While I usually see no winner in these debates, it does lead to some very interesting discussions.

I think we each have a lot to learn from project managers from other industries who face very different challenges from what we typically find on our own projects. Few project managers have experience across project types and the ones who do are usually highly valued by their employers.

Talk to your peers from other industries and learn from them what you can about what makes their own projects complex. I am sure that by doing so you’ll mature in your understanding of project management and perhaps you can take away a few tips to try on your own projects.

Kevin Aguanno, IPMA-B, PMP, MAPM is an executive project manager with a large IT services company and the Vice President of the Project Management Association of Canada. He has managed projects of different types including corporate strategy, event planning, course development, book publishing, software development, packaged software implementation, systems integration, commercial design/construction, and residential housing construction. Find out more at www.AgilePM.com.