Doing the Right Number of Projects

I have written about project portfolio management extensively. In all my articles I relentlessly repeated the three goals of Project Portfolio Management.

1) Maximizing the value of your portfolio

2) Seeking the right balance of projects

3) Creating a strong link to your strategy

After some thinking and new experiences, I have decided to add a very important goal.

4) Doing the right number of projects

Getting this one wrong makes it very hard, or even impossible, to achieve the other three. And as you probably already have guessed, doing not enough projects is seldom the case.

What Is the Right Number of Projects?

Typically the half of what you are currently doing. Of course the answer to this question is depending on the altitude of your portfolio (i.e. only IT, or your whole company), the size of your projects, and the size of your company. But there are a number of guidelines from the Agile and Lean world that we can use.

PMI project portfolio management is all about value optimization and optimizing resource allocation. Both are designed in such a way, that in my opinion it will result in the opposite. As we have seen in the article about funding, running projects at hundred percent utilization is an economic disaster. Any small amount of unplanned work will cause delays, which will be even worse because of the time spent on re-planning. And value is only created when it is delivered and not when it is planned. Hence we should focus on delivering value as quickly as possible with our given constraints.

This brings us to lean thinking. Lean is sometimes described as focusing on a smaller batch (project) size, shorter queues, and faster cycle time. Focus on delivering value quickly. Lean is much more than this. The pillars are respect for people and continuous improvement resting on a foundation of manager-teachers in lean thinking. Queue management is just a tool far from the essence of lean thinking. But it is a very helpful tool that can have a very positive impact on your project portfolio management process.

Some example of queues in project and portfolio management?
 > products or projects in a portfolio
 > new features for one product
 > detailed requirements specifications waiting for design
 > design documents waiting to be coded
 > code waiting to be tested
 > the code of a single developer waiting to be integrated with other developers
 > large components waiting to be integrated
 > large components and systems waiting to be tested

In lean thinking, work in progress (WIP) queues are identified as waste, and hence to be removed or reduced, because:

> WIP queues (as most queues) increase average cycle time and reduce value delivery, and thus may lower lifetime profit.

> WIP queues are partially-done inventory (of projects in this case) with an investment of time and money for which there has been no return on investment.

> As with all inventory, WIP queues hide—and allow replication of—defects because the pile of inventory has not been consumed or tested by a downstream process to reveal hidden problems; for example, a pile of un-integrated code.

On a similar note, we typically have a lot shared resource queues in our portfolio. Especially the main know-how carriers in a business unit are shared by multiple parallel projects. These queues are getting bigger due to project re-planning when one of them is behind schedule.

Also consider project portfolio throughput from a cost of delay point of view. You might, for example, be able to complete a project with perfect resource management (all staff is perfectly busy) in 12 months for $1 million. Alternatively, you could hire some extra people and have them sitting around occasionally at a total cost of $1.5 million, but the project would be completed in only 6 months.

What's that 6 months difference worth? Well, if the project is strategic in nature, it could be worth everything. It could mean being first to market with a new product or possessing a required capability for an upcoming bid which you don't even know about yet. It could mean impressing the heck out of some skeptical new client or being prepared for an external audit. There are many scenarios were the benefits outweigh the cost savings.

Additional to delivering the project faster, when you are done after 6 months instead of 12 months you can use the existing team for a different project delivering even more benefits for your organization. So not only do you get your benefits for your original project sooner and/or longer, you will get those for your next project sooner as well because it starts earlier and is staffed with an experienced team.

What Does This Mean for Your Organization?

For a typical organization this means the following five things:

1) Doing fewer projects in parallel (i.e. limit work in progress)). On average only half of what you are doing now. Focus on limiting the number of concurrent projects in your organizational units.

2) Focus on doing the right projects.

3) Keep your project size small (i.e. limit batch size)

4) Focus on improving your project delivery capability.

5) Implement an agile delivery method for projects where it makes sense (i.e. reduce cycle time because you deliver value during the project, and not only at the end)

Read more…

It Is Time to Face Your Project's Reality

Projects fail for many reasons: optimistic estimates; technology that doesn’t work as advertised; misunderstanding the needs of key stakeholders; plans driven by deadlines rather than feasibility; the belief of the team that given enough pizza they can solve any problem by tomorrow morning.

In my experience, many of these reasons come back to one root cause: we lose touch with reality. A few examples:

- We spend insufficient time exploring and validating assumptions at the start of a project, so we operate from different expectations of what’s required or how they’ll work together. This makes it almost impossible to build meaningful estimates and schedules. The project begins from a position of unrealistic expectations and is playing catch-up forever after. See my article “No validation? No project!”.

- We start with an over-optimistic assessment of our team’s capabilities and skills, or of the technology and methodologies, we are using. Initial slow progress is explained by lack of familiarity. Eventually, the reality of slower than expected progress hits us.

- Sponsors may not realize how much effort and commitment they need to put into sponsorship, or what skills will be required. They may assume that the project manager can handle many of the things that are properly their responsibility. A project with weak leadership will then have trouble connecting to broader organizational objectives.

- We negotiate poorly with key stakeholders. How often have you seen an executive beat down the initial estimate from a technical team? The team thinks they’re estimating, but the executive is conducting a negotiation. At least one person has lost touch with reality in this situation.

- Teams under pressure find it difficult to step back and think about what’s really going on. Minor problems pile up because everyone is so busy that they can’t see the underlying trend.

- Even if we can see the underlying trend, we have trouble reporting it. A culture that says “come to me with solutions, not problems”, may mean that unsolved problems don’t get talked about. A culture where senior managers are expected to have all the answers may mean that sponsors can’t admit it that they don’t understand what their project manager is saying. Often we just don’t know who to go to with their observations. People with problems have trouble connecting to people who may have solutions, and the project’s leadership remains disconnected from the real situation.

- And, of course, many of us don’t even want to think about what the real risks of the project might be.

This doesn’t happen because we are lazy, or because they are trying to sabotage their projects. Skills and experience may provide some insulation, but they don’t eliminate the problems completely. We lose touch with reality for reasons rooted in basic psychology. They are called cognitive biases. There are many of them, and most could impact your project. I will discuss the, in my opinion, most "dangerous" ones.

Overconfidence

"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts” – Bertrand Russel

We tend to overestimate our own ability. Surveys show, for example, that most of us consider ourselves to be above average intelligence, or to be better software developers than average, or to be better project managers than average. Likewise, most consultancies and system integrator claim a significantly higher success rate than the industry average. This specific effect of overconfidence is known as the Dunning-Kruger effect.

Overconfidence is a direct cause of underestimation on many projects. It helps driving phenomena like scope creep (developers think they can implement a feature with little effort) and the famous ninety-ninety rule.

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." - Tom Cargill, Bell Labs

Oversimplification

"Everything should be made as simple as possible, but not simpler" – Albert Einstein

We tend to use simplifying assumptions and mental model in order to deal with complexity. This is sometimes essential, for example when rapid decision making is important, but it can lead to unintended outcomes very fast. Most of us have been caught by time, cost and complexity estimates that escalate as we get further into the details. Yet most big projects are started with very broad, “high level” estimates.

Likewise, we often operate from mental models for how projects, teams or organizations should work. These are simplifications of reality; they embed large numbers of assumptions. If we use them unthinkingly, we fail to recognize situations where the assumptions are violated. We begin to operate in model land rather than the real world. Anybody who has done some work with one of the MBB management consultants should have experience with this. Not to mention the software and solution architects that have not done any real work since switching to PowerPoint architecture.

When we fail to recognize the true complexity of our projects, their requirements and the organizations that they are serving, we accept an unrealistic scope, estimates, staffing, and plans. We also fail to recognize and manage key risks.

Avoiding Pain

“Pain in this life is not avoidable, but the pain we create avoiding pain is avoidable” – RD Laing

We tend to avoid pain. I am not talking about physical pain, but emotional pain. Sometimes this means deferring immediate pain at the risk (or even certainty) of needing to deal with greater future pain. For example, rather to face up to a tough conversation now (“it probably can’t be done”), we take high-risk options (“the only way it can be done is if we cut all these corners and hope for the best”). Likewise, rather than going through the pain of admitting that we have been delayed, we find reasons to persuade ourselves that we will catch up by the next milestone. Like that will ever happen…

The pain we are avoiding comes from a variety of sources and is very much depending on your personality.

- We may be avoiding confrontation, anger or disappointment. This is why so many of us have trouble saying “no”. We would rather fail later than deal with anger or disappointment now. Especially with people we love, like, fear and/or respect.

- We may be avoiding the feeling for the loss of control or mastery. We may focus on tasks we are good at, rather than those that are important. Technical people often derive a lot of their identity from their ability to solve problems. Admitting they can’t solve a problem represents a deep threat to their sense of identity. Project managers who like to feel in control of the situation (which they never are), may avoid finding out or understanding things they can’t control (which are almost all important things in a project).

- We might be avoiding cultural taboos. Some teams and cultures have difficulties saying “no” because it is just not something you do. There are string cultural pressures to make “positive” responses. Many organizations find it difficult to discuss risks for similar reasons. There is a strong pressure to “smile, it probably never happens”.

- We might be avoiding loss of “face”. For example, senior managers find it difficult to admit their ignorance to the people reporting to them. Rather than seek clarification to status reports, they may allow things to drift. This is a common reason for weak project sponsors and steering committee members. They simply do not know how to help and do not want to ask. Strong project managers can manage/engage their StC and sponsor, but inexperienced project managers, who are most likely to need support themselves, can find this hard to work with.

- We may be avoiding apparent costs. Spending time to clarify objectives; allocating time to risk mitigation activities; undertaking further analysis of the problem; performing independent reviews and assurance. These all involve immediate costs with uncertain paybacks. There is often a string pressure to avoid these immediate and obvious costs in order to reduce the budget.

Confirmation Bias

“We tend to accept information that confirms our prior beliefs and ignore or discredit information that does not. This confirmation bias settles over our eyes like distorting spectacles for everything we look at." - Kyle Hill

We tend to look for evidence that confirms our existing hopes and beliefs. We want, for example, to believe that our project is on course so we seek evidence that shows we are hitting milestones and ignore information that shows where we are behind schedule. As a team makes commitments to budgets, estimates, schedules, and deliverables, this bias becomes more embedded. They begin to focus their energy on finding ways to achieve these commitments and to avoid any signs of problems or risks. The opposite can happen as well. As soon as a team believes the project will fail, it most probably will, because they will focus on finding reasons why it will.

Confirmation bias is often built in our project approval process. People say what they think they need to say in order to get the projects they believe in approved. They may not lie, but they focus only cursory attention to the costs, risks and side effects. This then becomes the approved version of the project’s storyline, to become embedded in people’s thinking through repetition.

Availability Cascade

"Vision without execution is hallucination." - Thomas Edison                    

The availability cascade is a self-reinforcing process in which a collective belief gains more and more plausibility through its increasing repetition in public discourse. If we hear a message often enough, we begin to believe it. This is the basis of most marketing and propaganda. Eventually, we may end up believing our own propaganda. A team takes initial, rough estimates and works with them, gradually losing sight of the fact that there is little basis behind them; a manager repeats the high-level vision to all who will listen and starts to mistake the vision for delivered reality.

Perceptual Bias

“How does a project get to be a year late? One day at a time” – Fred Brooks

We often find it harder to recognize gradual trends than sudden changes. We get locked into our view of individual details rather than seeing the big picture. When we are under pressure we see those days as individual, disconnected events and lose track of the bigger trend towards disaster.

Anchoring Effect

You've seen the anchoring effect in action a million times, usually in the form of a suggested retail price. When you see a purse with a price tag that claims it normally sells for $400, but is marked down to $200, that little "yippee!" you feel inside at the prospect of getting a bargain? The anchoring effect. The seller simply told you that the purse was worth $400, and we tend to accept this line of bull because we are basically trusting people and trained to use price as our gauge of value.

Anchoring is a cognitive bias that describes the common human tendency to rely too heavily on the first piece of information offered (the "anchor") when making decisions. During decision making, anchoring occurs when individuals use an initial piece of information to make subsequent judgments. Once an anchor is set, other judgments are made by adjusting away from that anchor, and there is a bias toward interpreting other information around the anchor.

So you can imagine now why your first rough estimations are maybe not so harmless.

Reinforcement Loops

All the above-described biases often combine and reinforce each other. We want to believe that we are above average at what we do, so confirmation bias reinforces our overconfidence. As we continue to confirm how good we are, repetition bias adds further reinforcement. This growing overconfidence makes us more prone to use pain-avoidance strategies. We assume we will be able to solve any problems, so we do not face up to potential difficulties or invest in analysis and risk mitigation. It is cheap to fly in two independent experts to validate your solution architecture for your multimillion software development project compared to finding out later that your design will not work and you could have known this from the get-go. Those experts might even have some other great tips and tricks as well.

Organizational Accelerators

“The limits of my language means the limits of my world.” - Ludwig Wittgenstein

On top of the biases and their reinforcement loops, we have the organizational culture that can make things worse.

Organizations that focus on looking for blame instead of solutions increase the pain associated with admitting problems increasing the chance that people will hide them till the very end. Strong hierarchical organizations can increase the pain associated with confrontation or loss of face (think Yakuza), making it difficult for people at a different level to admit their uncertainties to each other. Organizations with a strong collegial culture have a higher risk of “groupthink”, the tendency for people in a group to converge on consensus at the expense of critical examination.

Projects that span organizational boundaries face additional challenges. You have to deal with not one, but multiple cultures. This is especially true in joint ventures and outsourcing relationships that involve multiple organizations. But is also effects projects working across group and unit boundaries within a single organization.

People may be uncertain as to what information can be shared or how it should be shared. Different professional backgrounds, languages, and conventions may make it difficult to understand the information that is shared.

Contracts and legal concerns can create further barriers. Penalty clauses, for example, may help align objectives across organizations, but they also create incentives to hide problems and to be very reluctant in supporting change. Procurement regulations may restrict what information can be shared at key stages in the project. All these barriers can make it harder for people to uncover and deal with all the biases described above.

Closing Thoughts

Underlying all this, reality does not always gives us the message we would like to hear. We do not want to hear that we are less intelligent than we would like, or less capable of solving problems, or that we code too slowly. Project failure is one of the prices we pay to avoid (or at least delay) hearing these messages.

Eventually, however, our projects come face-to-face with reality. Something will happen that we cannot ignore anymore. Unfortunately, by the time this happens, it is often too late.

This is why project reviews exist. They are a way to help teams, sponsors, project managers, or other stakeholders manage these human biases and keep in touch with what is really happening on their projects. Of course, they are not the only way. Test automation, project validation, iterative delivery, financial controlling, real estimations, pair programming and many others will help reducing the biases. But every now and then a project review can save you many headaches.

Read more…

Five Types of Reviews for Projects

Reviews can serve a wide range of stakeholders and fulfill a variety of roles. It’s therefore not surprising that organizations undertake several different types of review on there most important projects. From my perspective, there are five distinct types of review. Each with its own focus and outcome.

1) Project Review

Can happen at any point through the project. It checks progress against the original schedule, budget, and deliverables. It looks at the effectiveness of the team, project management, engineering practices, and other related processes. It typically delivers some sort of assessment of the likelihood of project success and identifies areas of concern and corrective actions. This kind of review is also known as a Project Healthcheck or Project Evaluation. These are the kind of reviews I mostly do. Typically as part of a project recovery process.

2) Gate Review

Happens at the end of a project phase or at some other defined point in the project’s lifecycle. It typically represents a decision point, using the outputs from an evaluation to decide whether continued investment in the project is justified.

3) Project Audit

An objective evaluation by a group outside the project team. A project audit is about being compliant and about the now. An audit aims to show the extent to which your project conforms to the required organizational and project standards. So, if your organization uses PRINCE2 or their own project management methodology, an audit will look at how closely you follow the processes. An audit can take place during or after the project.

4) Project Retrospective

Happens as the project closes down. It assesses the overall success of the project and identifies what did or didn’t work during its execution, generating lessons learned for the future. Also known as Postmortem or Post-project Review.

5) Benefits Realization Review

Happens after the organization has had some chance to use the outputs from the project. It evaluates the extent to which the benefits identified in the original business case have been achieved.

Read more…

How to Do a Project Delivery Team Review

In my experience, most issues that arise in software development projects are people issues, not technical ones. DeMarco and Lister showed this in their highly recommended book Peopleware: Productive Projects and Teams already two decades ago, and many others after them as well. Successful projects consistently give significant weight to the human factor.

An important part of the project reviews I do is the project delivery team review. The project delivery team consists of the project team (developers, testers, solution architect, business analysts, and so on), the project manager, project management office and line managers. Stakeholders, sponsor, and Steering Committee are not part of this project delivery team review. These are covered in a separate review because the focus there is a completely different one. From here on I will refer to the project delivery team just as the team.

When reviewing a team I usually look at three levels:

1) Team performance
2) Project management
3) Team members

These are not three separate reviews, but rather three overlapping perspectives of the team, which are part of a single review. While a substantial part of the interviewing can be performed concurrently, information from the review of team performance will provide input to the project management review, which will then provide input for the team member reviews. This will be discussed in detail in the following sections.

Team Performance

I start with a review of the project delivery team and focus on the performance of the team as a unit. Interview the initiating manager to get a general perspective of the team, and then meet with the project manager and other parties who interface regularly with the team (interviews can be conducted with multiple participants). The following list covers ten key issues that should be considered during your review and resulting interviews:

1) General team performance: Look at the team as a single unit. How well does the team perform? Are team activities well coordinated, and do team members cooperate well with each other? Look at the team’s accomplishments. Were they due to teamwork, or would individual team members working on their own have achieved them in any case? Look at the team’s setbacks: Could better teamwork have prevented them? How has the team performed over time? Has performance improved or declined?

2) Skill set: Look at the skill set necessary to deliver the project: Does the team have these skills? Does the team have the necessary experience? Are the team member’s skills up to date? Does the development organization have a training program for software developers, and if so, is the team taking advantage of the program? See my article "14 Essential software engineering practices for your agile project" for more background and ideas.

3) Unstaffed positions: At this point, we are not yet looking at understaffing (budgeting for a team that is too small to deliver the project); rather, we are looking at budgeted team positions that have not been filled. Are all approved team positions staffed? If not, for how long have unstaffed positions been empty? Is the project manager constantly looking for new people to fill empty positions? Are the right people in the right roles? Are positions part-time staffed that should be fulltime staffed?

4) Size of team: Look at the size of the team that has been budgeted in relation to the amount of work to be done. Is the team understaffed (too small)? Is the team overstaffed (too big)? Note that in some cases, overstaffing can be a problem (redundancy, overlapping responsibilities, greater management overhead, budget used for the wrong things). How bad is the understaffing or overstaffing?

5) Development facilities: Look at the facilities and tools available to the team. Does the team have the necessary development tools to deliver the project? Do team members have an appropriate workspace, desks, chairs, powerful laptop/pc, 2 screens, and meeting rooms? Does the team have the necessary communications facilities (chat, Kanban board, whiteboards, flipcharts)? Does the team have enough support (administrative support, technical support, PMO)?

6) Organization of team(s): Is the software being developed at a single location, or is it a distributed team? How is the team distributed (different offices, different companies, different countries, offshore, nearshore)? How is the team mixed (internal vs external, location vs location, junior vs senior)? Does the mix and/or split make sense? Would it not be better to have one team at one location? Is the team a feature team or a component team? See my articles "Agile Team Organization" and "Outsourcing technical competence" for more background and ideas.

7) Team atmosphere: Clearly, the failure of a project will affect the morale and spirit of the team. But is there anything else that is causing low morale (if so, what is it)? Is there a lack of commitment to the project. Do team members seem to like each other, goof off together, and celebrate each other's success? Do team members hold each other accountable to high standards, and challenge each other to grow?

8) Relationships with other groups and teams: Look at the project team’s relationships with other external groups and teams. How well do they work with the infrastructure team, the independent test team, the field support team, the architecture team, stakeholders and other projects?

9) Conflicts: Are there any internal or external team conflicts or tensions that could disrupt the project? How long have they existed? How severe are they? Have there been attempts to resolve them? How did this go? Are there issues/opportunities the team isn't discussing because they're too uncomfortable?

10) Management: How good is the relationship between the team and management (the project manager and line management)? Is line management aware of the team problems? Have there been any attempts to resolve the problems? Have the managers responsible for the project been changed recently or frequently? Does line management still support the project and the team?

These ten points are not distinct, meaning that they do not need to be covered separately (they are not a checklist in the sense that you finish one and move on to the next). The review, interviews, and meetings can cover a broad range of topics at a single session, and some of the topics can be discussed concurrently. Use the input from the team performance review to prioritize the later interviews with the individual team members and the other project stakeholders. This way you will be able to put the main pieces of the picture in place more quickly. Reevaluate the priorities after each interview or meeting, and be prepared to repeat interviews when new questions and information comes on your path.

Project Management

The project management review focuses mainly on the leadership (not the administrative / PMO) aspects of the project and considers the main problems confronting the project manager and the way they are handled.

Very often, project managers are the first to be blamed for a failed project. It is important, however, to remember that projects fail for many reasons, several of which are unrelated to the qualities of the project manager. You should approach the review with no preconceptions. Although senior management may sometimes instinctively blame project management, it is your responsibility, after examining the facts, to independently determine if there are any major incompatibilities between the qualities of the project manager and the needs of the project. This is especially important because of the personal impact of your evaluation results.

1) Skills: Look at the main skills required for the project (avoid a comprehensive wish list for an ideal project manager). Concentrate on core skills without which it is clear that the project manager will not be able to successfully lead the project. Does the project manager have these skills? In my opinion for a software development project these skills consist of:

- a good understanding of the software development process
- a good understanding of the business and the business problem that will be addressed
- leadership skills
- project management skills

2) Relationships: How do others perceive the project manager’s ability to successfully lead the project? Look at the quality of the project manager’s relationships with the following groups:

- Team: Look at individual relationships, respect as a leader, and loyalty. Have there been any severe conflicts?
- Senior management: Look at individual relationships with key managers, issues of respect, and confidence in the project manager’s required capabilities. Have there been any severe conflicts?
- Other groups: Look at the working relationship with project support groups, such as the test group, quality assurance, field support, marketing, other projects, and so on.
- Other project stakeholders: In addition to senior management, look at the relationship with customers, users, investors, sub-contractors, partners, and so on.

Have any of these relationships contributed to problems? If other project problems are solved, does the disturbed relationship(s) still endanger project success? See my article "10 Principles of Stakeholder Engagement" for more background and ideas.

3) Confidence in the project: Is the project manager confident that the project can be realized? Is doing the project worth the effort? In the project manager’s opinion, what are the top three well-defined things that need to be done to get the project done?

4) Spirit, motivation, commitment: How committed is the project manager to the success of the project? Look at the project manager’s personal identification with the project, the amount of time invested in the project (full time, part-time, and so on), loyalty to the project team, and more generally the level of enthusiasm in making the project a success. Clearly, much of this is related to the previous point.

5) Other problems: What other problems related to the project manager may have contributed to a negative impact on the project? Consider, for example, personal problems or sickness.

6) General capabilities: Based on points 1 to 5 look at the project manager’s overall ability to successfully manage the project (leadership, personality, competence, and so on). Concentrate only on major points (remember that this is not a performance review). Ask the following question: If other project problems (that are unrelated to the project manager’s work) are solved can the project manager lead the project to success?

Team Members

This review will identify team member problems that can prevent the project from being successfully completed. This is achieved through individual interviews that focus on the team problems identified during the team unit review. It is important to remember that this is not a performance review for the team members, and it is not concerned with problems that will not affect the overall success of the project.

If the team is large, there may not be sufficient time to meet with all team members individually—in such cases, select the ones relevant to the main team problems that have already been uncovered.

The following list includes seven key points to be considered during the individual team member interviews:

1) Role: Determine the team member’s official job function, his/her description of their role in the project, and compare it with the role as described by the project manager. Are there significant discrepancies? When the person's role is ScrumMaster have a look at the ScrumMaster Checklist.

2) Skills: Does the team member have the skills necessary to perform the project team role (avoid a comprehensive wish list and concentrate only on the main skills)?

3) Achievements and contributions: Look at the results (not effort) of the team member’s work on the project so far. What have been the main contributions to the project? Have the team member’s activities been a factor in the success/failure of the project? If so, how big is this factor?

4) Relationships: Look at the team member’s relationship with other persons involved in the project, including:

- Other team members
- The project manager
- Members of other groups/teams
- The project stakeholders

Are any of these relationships problematic? If so, how serious are the problems and how do they affect the project?

5) Morale and commitment issues: Does the team member have any motivation issues that go beyond the situation of the project? How committed is the team member to the project and especially to the attempt to bring it to success? Can the team member be expected to stay with the project if a recovery plan is implemented?

6) Other problems: What other problems have affected the team member’s work on the project? Look at issues such as work environment, tools and facilities, training, and personal problems.

7) Capabilities: Based on the points (1 to 6) look at the team member’s overall ability to successfully perform the role. Concentrate only on major points. Ask the following question: If a new project plan is implemented, will the team member be capable of successfully fulfilling the requirements of the, potentially new, role?

Results

As described in the previous sections there are several sources of information, and three different levels, for the evaluation of the project delivery team. The goal of the project delivery team review is to combine the information to form a single coherent view of the team. I usually do the following:

1) Complete and write down my view of things, identify information/evidence gaps and identify contradicting information. 

2) Archive all interview minutes/recordings, received documents, written documents, and all related emails. This will save substantial time if the findings ever need to be re-examined.

3) Prepare a short team overview document. The document should be no more than 3–6 pages (depending on the size and complexity of the team) and should take between two and four hours to prepare. Include the main sources of information, the list of interviews, the reasoning that led to any significant findings, and any problems or incompatibles that arose during the evaluation.

4) Review the overview with the initiating manager. Review a draft of the document with the initiating manager. Expand any key points that are unclear and correct any factual errors.

5) Adjust the evaluation. Additional information about the team may well continue to emerge throughout the disentanglement process. If any of the new information affects your main findings, be prepared to adjust your conclusions. However, avoid frequent changes to your findings, especially when the new data does not significantly affect your key conclusions.

Due to the information on individual team members, the team overview document cannot be considered a public document. However, a summary of the findings should be available to the team and to the project stakeholders (consult with the initiating manager regarding any business reasons to limit distribution).

Read more…

The 5 principles of project success

Just finished reading the book "Performance-Based Project Management" from Glen B. Alleman. You might know him from his very popular blog on project management "Herding Cats", which I love and recommend reading. He writes great in-depth articles and has very interesting views on project and risk management.   

Whilst reading his book I found lots of things I see the same, but just as many things that I cannot imagine practicing on the type of projects I work on. I am not sure if I would disagree yet. I am absolutely not familiar with doing projects for the American Department of Defence or NASA so working with Earned Value Management might work there. I have to think a while on how I could translate this into something workable for large financial modeling projects, building an online insurance portal, or building a new intranet/extranet for a professional service company. This is something for a future article.    

One chapter where I was just nodding in agreement and recognition was the chapter "The five immutable principles of project success". These five immutable principles are applicable to every project in every business and technical domain. That is the definition of immutable - they never change and are universally applicable. 

Capabilities

Project failure starts when we can’t tell what “done” looks like in any meaningful way. Without some agreement on our vision of “done”, we’ll never recognize it when it arrives, except when we’ve run out of time or money or both. We’ve all seen the project failure numbers before. We’ve all been told how bad things are. We’ve all heard that large numbers of projects fail because of poor planning or poor project management. Whether this is true or not, how can we increase the probability of our own project’s success?

First, we must recognize that without a clear and concise description of done, the only measures of progress are the passage of time, consumption of resources, and production of technical features. These measures of progress fail to describe what business capabilities our project needs to produce or what mission we are trying to accomplish. Capabilities drive requirements. Therefore, without first identifying the needed capabilities, we cannot deliver a successful project, and we will end up a statistic like all the other failed projects.

With capabilities as our starting point, we’re now going to look at the Five Immutable Principles of project success as they apply to any project, in any domain, using any project management method and any project management tool. 

Five principles

The Five Immutable Principles are best stated in the form of five questions. When we have the answers to these questions, we will have insight into the activities required for the project to succeed in ways not found using the traditional process group’s checklist, knowledge areas, or canned project templates.

1) What does “done” look like? We need to know where we are going by defining “done” at some point in the future. This may be far in the future—months or years—or closer—days or weeks from now.

2) How can we get to “done” on time and on budget and achieve acceptable outcomes? We need a plan to get to where we are going, to reach done. This plan can be simple or complex. The fidelity of the plan depends on our tolerance for risk. The complexity of the plan has to match the complexity of the project.

3) Do we have enough of the right resources to successfully complete the project? We have to understand what resources are needed to execute the plan. We need to know how much time and money are required to reach the destination. This can be fixed or it can be variable. If money is limited, the project may be possible if more time is available and vice versa. What technologies are needed? What information must be discovered that we don’t know now?

4) What impediments will we encounter along the way and what work is needed to remove them? We need a means of removing, avoiding, handling or ignoring these impediments. Most important, we need to ask and answer the question, “How long are we willing to wait before we find out we are late?”

5) How can we measure our progress to plan? We need to measure planned progress, not just progress. Progress to plan is best measured in units of physical percent complete, which provides tangible evidence, not just opinion. This evidence must be in “usable” outcomes that the buyer recognizes as the things they requested from the project.

Conclusion

It does not matter what approaches you take to manage and deliver your project. The five principles are valid and the questions that follow from it should be answered when you want to have a good chance at success. When you have not done so yet look at the current project you are involved in and answer these questions, or when you have some time to think and review on past projects take a successful one, and one or two failed ones and answer these questions. I did the same exercise, and it validated what Glen has written in every way.

I have written a previous article about project success where I address numbers 1 and 5 in a different way. The message is the same. When you do not know what success looks like, and do not know how to measure it, you will have a very hard time having success.

Read more…

8 Benefits of Working With an External Project Recovery Manager

Often people ask me why they should hire an external consultant to help them with a troubled project. The most heard arguments are. "He/she does not know our organization, our way of working, our project, etc. While this is mostly true there are a number of benefits that can tip the scale in favor of working with an external consultant on a project recovery. Here are eight of them:

1) The project recovery manager brings in a set of skills missing from the organization. These skills could be in managing certain risk, managing change, working with remote and/or outsourced teams, handling demoralized teams, rectifying problems in the management chain, software development processes, or managing the customer.

2) The project recovery manager brings in experience with troubled projects, project recovery and ideally with projects of a similar type. In my case, for example, I only work on software development, financial modeling, and system migration projects because that is what I deeply understand and have lots of experience with.

3) The project recovery manager is new to the group and brings a fresh set of ideas and views to the project.

4) It is common for external project recovery managers to get the ear of executives simply by virtue of the fact that they are from outside. Ideas they propose may be similar to those offered by the project team in the past, but management listens to them without significant questions. This is the result of the psychology of having a consultant make the statement, as well as the benefit derived from the honeymoon period that accompanies any new relationship. Regardless of the reason, management tends to adopt consultants’ suggestions more quickly.

5) External project recovery managers have no history with the team—there is nothing preconceived about the project or the people. They can be objective and review the staff and the processes without the bias of familiarity with people’s personalities and previous actions.

6) Team members also tend to be more open with an external than with other team members. They open up to an outsider because they feel their comments are less likely to be judged or biased. Team members with a history of being quiet can become vocal, as they now feel their views will be heard. As a result, an external project recovery manager can uncover issues hidden to others in the organization.

7) Most recovery projects require that difficult decisions be made and executed. This might include reducing scope, canceling contracts, or removing team members. Often these actions result in lingering animosity. By using a project recovery manager with a relatively short tenure, many of these negative feelings leave with that person. This can help diffuse some contentious situations.

8) In the negotiation step, the project recovery manager mediates the solution for both sides. If this person is an outside party, neither the customer nor the supplier should perceive any bias. The recovery manager can propose a solution without the perception that he or she is trying to gain some tactical advantage or get the upper hand. The negotiation is fair and even.

Conclusion

Selecting the right project recovery manager can bring an entirely new set of ideas and skills to the organization. These include prior project recovery experience, objectivity, new processes, new procedures, and attention to detail.

If the project has a technical component, the recovery manager should have a strong technical background so that he or she can talk with the technical team on its own level, gaining trust as someone who understands the challenges. This must be coupled with an independent critical eye questioning the direction. Many aspects of technology development can contribute or even cause trouble on a project.

A project recovery manager grounded in accepted best practices, as well as the latest in technological advances, tools, and methodologies, is invaluable in determining where problems may manifest themselves.

Read more…

A Step by Step Stakeholder Mapping Guide

Stakeholder Engagement and Stakeholder Management is essential for defining and realizing project success. One important tool to help you with this is stakeholder mapping. This article provides a step by step guide on how to do this effectively.

You will learn how to analyze stakeholders by interest and influence to identify key players, potential saboteurs, advocates and avoid time wasters. Following the steps in this article, you can develop a sound plan to engage the most important people in your project - your stakeholders.

What Are Stakeholders?

You can think of stakeholders as "Anyone who has a stake in the project" although this can be a bit broad. A more workable definition might be: "Anyone who can make, or break, your project".

This group of more specific stakeholders can be segmented into four major groups:

1) Sponsors are often those who initiate the project by mobilizing the resources needed and charging people with the responsibility for getting it done. Sponsors own the requirement for the project - and if the requirement changes they must direct the project accordingly.

2) Project Team are those charged with the responsibility for executing the project and ensuring it happens. The project team is responsible for coming up with the solution to the project requirements.

3) Reference Group include those people that project teams must refer to in order to arrive at the right solution. They ensure that the solution will work.

4) Users are a broad group of people who benefit from the project solution. 

Tip: The Reference Group and some of the Project Team may also be classed as Users. This is often a very good idea.

What Exactly is Stakeholder Mapping?

Stakeholder mapping is a collaborative process of research, debate, and discussion that draws from multiple perspectives to determine a key list of stakeholders across the entire stakeholder spectrum.

Mapping can be broken down into four steps:

1) Identifying: listing relevant groups, organizations, and people

2) Analyzing: understanding stakeholder perspectives and interests

3) Mapping: visualizing relationships to objectives and other stakeholders

4) Prioritizing: ranking stakeholder relevance and identifying issues

The process of stakeholder mapping is as important as the result, and the quality of the process depends heavily on the knowledge of the people participating.

Tip: Gather a cross-functional group of internal participants to engage in this process. Identify sources external to the company who may have important knowledge about or perspective on the issues, and reach out to these sources for input and participation. Finally, identify a resource who can facilitate your work through the following activities. Capture all your work in writing to help with future steps.

Why Should You Do This?

The Stakeholder Mapping process will help you with the identification of the following:

> Sponsor's real goals
> Stakeholder's interests
> Project success
> Effective communication plan
> Mechanisms to influence other stakeholders
> Potential risks
> Key people to be informed about the project during the execution phase
> Negative stakeholders as well as their adverse effects on the project

Step 1: Identifying

The first step in the mapping process is to understand that there is no magic list of stakeholders. The final list will depend on your business, its impacts, and your current project objectives—as a result, it should not remain static. This list will change as the environment around you evolves and as stakeholders themselves make decisions or change their opinions.

Tip: Brainstorm a list of stakeholders without screening, including everyone who has an interest in your objectives today and who may have one tomorrow. Where possible, identify individuals.

Step 2: Analyzing

Once you have identified a list of stakeholders, it is useful to do further analysis to better understand their relevance and the perspective they offer, to understand their relationship to the project and each other, and to prioritize based on their relative importance for this project. You can use the following list of criteria to help you analyze each identified stakeholder:

a) Stakeholder Type: Sponsor, Project Team, Reference Group or User.

b) Contribution (value): Does the stakeholder have information, counsel, or expertise that could be helpful to the project?

c) Legitimacy: How legitimate is the stakeholder’s claim for engagement?

d) Willingness to engage: How willing is the stakeholder to engage?

e) Influence: How much influence does the stakeholder have? (You will need to clarify “who” they influence, e.g., other stakeholders, teams, departments, investors, clients, etc.)

f) Involvement: Is this someone who could derail or delegitimize the process if they were not included in the project?

Tip: Use these six criteria to create and populate a spreadsheet table with short descriptions of how stakeholders fulfill them. Assign values (low, medium, or high) to these stakeholders. This first data set will help you decide which stakeholders to engage.

Step 3: Mapping

Mapping stakeholders is a visual exercise and analysis tool that you can use to further determine which stakeholders are most essential to engage with. Mapping allows you to see where stakeholders stand when evaluated by the same key criteria and compared to each other and help you visualize the often complex interplay of issues and relationships created in the criteria chart above.

a) Draw the stakeholder map with two axes. The x-axis represents the spectrum of dispositions toward your change project; from "Against" at one extreme - to "For" at the other. The y-axis represents the spectrum of involvement from high at the top to none at the bottom.

b) The group discusses each stakeholder, in turn, determining their location on the map by rating their relative sentiment towards your project and the degree to which they are actively involved in it (use the example sentiment slide below to help you decide where each should sit).

<click image to enlarge>

c) The example below illustrates some typical stakeholder sentiments towards a school change initiative. Ideally, you would want everyone to be at the top right-hand corner - actively involved and championing your project! But in reality that is not going to happen. This example shows a broad landscape of diverging sentiment and involvement that is more typical.

Related articles:
> How to Deal With Stakeholders Resistance to Change
> Successful Projects Need Executive Champions

<click image to enlarge>

d) The last step in the mapping exercise is to add a final dimension: this is the relationships that exist between stakeholders.

<click image to enlarge>

e) Draw lines that connect two stakeholders in your map where a relationship currently exists. The thickness of the line can indicate your rating of the relative strength of that relationship - the closer the relationship, the thicker the line. This represents another aspect of the underlying political situation and is helpful to know.

f) In the effort to shift dispositions to a more favorable situation you might want to exploit the relationship that exists, say, between a strong supporter of your project and someone else who remains skeptical or even cynical.

Tips:

> It is wise to know the sentiment of each of the broad groups of stakeholders towards your project. Are they actively supportive, or unsure, skeptical or even against the project? Stakeholder mapping illustrates these sentiments - so that you can determine what action you need to take in order to shift unfavorable sentiments more positively.

> The size of the circle is an important dimension to the success of your project. You want the most influential stakeholders on the right of your map and migrating to the top so if they're not you need to work out a way to get them there.

> Note that relationships can be negative as well as positive. The assumption can be that all relationships are positive ones. If you think it is relevant, you might want to illustrate a negative relationship with a broken line.

> Be careful, because stakeholder maps can contain the identities of individuals. Never print or leave your map lying around. The data in your stakeholder map represents your perceptions about other people - and they may not necessarily agree with you! So it is wise to keep this sensitive information very confidential.

Note: This is just an illustrative mapping example, and your approach may vary depending on your needs: You may need to use more or fewer criteria in "Analysis" depending on the mix of your stakeholder list; more ambitious objectives may require a more strategic, detailed Mapping; and your process may be influenced by outside variables such as tools and frameworks already in place at your company. Look closely at your needs and decide whether this example will work for you as is.

Step 4: Prioritizing stakeholders and identifying issues

It is not practical and usually not necessary to engage with all stakeholder groups with the same level of intensity all of the time. Being strategic and clear about whom you are engaging with and why, before jumping in, can help save both time and money.

An often used base strategy for stakeholder management based on the information you collected in the previous steps (influence and interest) is the following:

<click on image to enlarge>

Tip: Look closely at stakeholder issues and decide whether they are material to your project objectives, asking yourself the following questions:

> What financial or emotional interest do they have in the outcome of your work? Is it positive or negative?

> What motivates them most of all?

> What information do they want from you?

> How do they want to receive information from you? What is the best way of communicating your message to them?

> What is their current opinion of your work? Is it based on good information?

> Who influences their opinions generally, and who influences their opinion of you? Do some of these influencers, therefore, become important stakeholders in their own right?

> If they are not likely to be positive, what will win them around to support your project?

> If you don't think you will be able to win them around, how will you manage their opposition?

> Who else might be influenced by their opinions? Do these people become stakeholders in their own right?

A very good way of answering these questions is to talk to your stakeholders directly - people are often quite open about their views, and asking people's opinions is often the first step in building a successful relationship with them.

Combined with your criteria table and different mappings, use issue materiality to rank your stakeholders into a prioritized engagement list. You should now have captured the most relevant issues and the most relevant stakeholders.

In a nutshell: A stakeholder is anyone who can make, or break, your project. You need to identify, understand, and prioritize them.

Read more…

10 Principles of Stakeholder Engagement

Stakeholder engagement and stakeholder management are arguably the most important ingredients for successful project delivery and yet are often ignored or undervalued.

On the opposite side, I have also worked with project managers that were so busy with stakeholder management that they forgot they also have to deliver a project. Whole project teams were working for days on StC Powerpoint decks instead of the actual project!

Project managers depend on people to respond to the outputs and benefits that they deliver. People will only respond if they are engaged. The phrase “stakeholder management" implies that these people can be made to respond positively to a project, but the truth is that a project manager in most cases has no formal power of authority and therefore has to rely on engagement to achieve his/her objectives. And this is a good thing!

What Exactly is Stakeholder Engagement?

Stakeholder engagement is the practice of interacting with, and influencing project stakeholders to the overall benefit of the project and its advocates.

Stakeholder Engagement is the practice of influencing a variety of outcomes through consultation, communication, negotiation, compromise, and relationship building.

The successful completion of a project usually depends on how the stakeholders view it. Their requirements, expectations, perceptions, personal agendas and concerns will influence the project, shape what success looks like, and impact the outcomes that can be achieved. Successful stakeholder engagement is an essential part of professional project management.

Stakeholder Engagement vs. Stakeholder Management

Stakeholder Engagement differs from Stakeholder Management.

Stakeholder Management is a process that can be defined as: “the systematic identification, analysis, planning, and implementation of actions designed to engage with stakeholders”. 

By contrast, Stakeholder Engagement is the practice of influencing a variety of outcomes through consultation, communication, negotiation, compromise, and relationship building.

Key principles of stakeholder engagement

#1 Understand

Before aiming to engage and influence stakeholders, it’s crucial to seek to understand the people you will be working with and relying on throughout the phases of the project lifecycle. Sharing information with stakeholders is important, but it is equally important to first gather information about your stakeholders. One technique that can help with this is Stakeholder Mapping. See my Stakeholder Mapping Guide on how to do this.

#2 Communicate

There have been numerous studies into why projects fail, with ‘bad communication’ often pointed to as the most common reason. Across all sectors and sizes of project, ineffective or insufficient communication is at the root of project problems such as unclear objectives, misunderstanding the problem, poorly coordinated teamwork and ineffective risk management. The fundamental challenge of effective communication is based on the clear evidence that ‘what you say is not the same as what they hear’, even with people you know very well. It is therefore easy for communications to be misinterpreted. Good communication requires relentless and time-consuming effort to ensure the intended message is understood and the desired response achieved, which, especially on large projects, sometimes justifies the assistance of communication professionals.

#3 Consult, early and often

The rewards of early and efficient stakeholder consultation should be clear to anyone that has worked on a project where this has not been done well. If you have ever felt ‘I wish I’d known that at the start of the project,’ then consider that even just a few, well-timed questions can be very valuable. Questions about who the relevant stakeholders are (e.g. ‘Who else’s views should we be considering?’), and, once these have been identified, questions about the stakeholders’ objectives, success criteria, constraints, key concerns, their stakeholders (e.g. customers), etc., usually provide information that easily justifies the time spent investigating.

#4 They are human too

Accept that humans do not always behave in a rational, reasonable, consistent or predictable way and operate with an awareness of human feelings and potential personal agendas. By understanding the root cause of stakeholder behavior, you can assess if there is a better way to work together to maintain a productive relationship.

#5 Plan it!

A more conscientious and measured approach to stakeholder engagement is essential and therefore encouraged. Investment in careful planning before engaging stakeholders can bring significant benefits. What kind of regular meetings have value? How are they structured? Formal meetings with meeting minutes, or informal ones? This is what Stakeholder Management is.

#6 Relationships are key

Developing relationships result in increased trust. And where there is trust, people work together more easily and effectively. Investing effort in identifying and building stakeholder relationships can increase confidence across the project environment, minimize uncertainty, and increase the speed of problem-solving and decision-making.

#7 Just part of managing risk

Stakeholders are important influential resources and should be treated as potential sources of risk and opportunity within the project. Over and above conventional planning, using foresight to anticipate hazards, and taking simple and timely actions with stakeholders can significantly improve project delivery. See "Risk Management Is Project Management for Adults" for more insights.

#8 Compromise

The initial step is to establish the most acceptable baseline across a set of stakeholders' diverging expectations and priorities. Assess the relative importance of all stakeholders to establish a weighted hierarchy of the project requirements and outcomes. Having ranked the stakeholders in order of importance, their differing interests can then be weighed accordingly with the best compromise solution being at the ‘centre of gravity’. As the leader of the project, it is your judgment as to what this solution is with the rationale and decision being communicated to all parties where appropriate.

#9 Understand what success is

Project success means different things to different people and you need to establish what your stakeholders perceive as a success for them in the context of project delivery. See "The Project Success Model" for more insights.

#10 Take responsibility

Stakeholder engagement is not the job of one member of the project team. It’s the responsibility of everyone to understand their role and to follow the right approach to communication and engagement. Good project teams have clarity about stakeholder engagement roles and responsibilities and what is expected of people involved in the project. See "Taking and Giving Responsibility as a Project Sponsor" for more insights.

When you need some guidance on how to define and measure project success, just download the Project Success Model by clicking on the image.

Read more…

Why Halting Your Project During the First Steps of Recovery Is Essential

When you know that you have a seriously troubled software project at your hands the first step in the process of recovery is halting all development activity.

Would it not be better to have the project, which is already late and over budget, continue while the recovery process is being implemented? There are five good reasons why the recovery process will have more difficulty to succeed if development continues in parallel.

1) The recovery process requires the full involvement of the key project members. Project Manager, Developers, Scrum Master, Product Owner, Product Manager, Business Analysts, Stakeholders, and so on. If development is not halted those key persons will be scrambling to keep the project going. Halting the project ensures that everyone is completely focused on the recovery process, and thus increase the likelihood that this process will succeed.

2) Project recovery requires painful decisions to be made by the key stakeholders and team members. Reducing scope, increasing budget, rebuilding the team, hiring and firing, and so on. It is only natural that there will be resistance to these changes. Experience shows that it is highly unlikely that the necessary decisions will be made and a feasible project will be re-defined unless everyone involved understands that the project will not be allowed to continue in the current mode that has led to this situation. 

3) Troubled projects will have a large amount of sunk costs. Continuing development on a scope that will be disregarded in the Tradeoff and Negotiation Phase will just add to these sunk costs and frustration of the development team.  

4) In my experience often part of the reason why software development projects end in a disaster is the software development process and practices that are used. Unless they are validated as decent or better, continuing development makes to problem worse instead of better.  

5) Halting the project sends a very strong message that this time "we are serious". It clearly sets the recovery process apart from all previous attempts to get the project back on track by conventional means like adding people, working overtime, extending the schedule, and so on.

After the project is halted the Review Phase of the recovery process can start.

Read more…

12 Benefits of Test Automation

1. Saves time and money

Software tests have to be repeated often during development cycles to ensure quality. Every time source code is modified software tests should be repeated. For each release of the software, it may be tested on all supported operating systems and hardware configurations. Manually repeating these tests is costly and time-consuming. Once created, automated tests can be run over and over again at no additional cost and they are much faster than manual tests. Test automation can reduce the time to run repetitive tests from days to hours. A time saving that translates directly into cost savings. It is of no surprise that, while the initial investment may be on the higher side, automated testing saves companies a lot in the long run. It contributes to a higher quality of work, thereby decreasing the necessity for fixing glitches after release and reduces project costs.

2. Improves accuracy

Even the most conscientious tester will make mistakes during monotonous manual testing. Automated tests perform the same steps precisely every time they are executed and never forget to record detailed results. Developers freed from repetitive manual tests have more time to create new automated tests and deal with complex features

3. Automation does what manual testing cannot

Even the largest software development and QA departments cannot perform a controlled web application test with thousands of users. Automated testing can simulate tens, hundreds or thousands of virtual users interacting with a network, devices, software and web applications.

4. Increases your test coverage

Test automation and automated tests can increase the depth and scope of tests to help improve software quality. Lengthy tests that are often avoided during manual testing can be run unattended. They can even be run on multiple computers with different configurations. Automated software testing can look inside an application and see memory contents, data tables, file contents, and internal program states to determine if the product is behaving as expected. Test automation can easily execute thousands of different complex test cases during every test run providing coverage that is impossible with manual tests.

5. Run tests 24/7

No matter where you are in the world. You can start the tests when you leave the office and when you get back in the morning you can see the results and keep on working. You can even do that remotely if you don't have a lot of devices or you don't have the possibility to buy them.

6. Faster feedback

Test automation comes as a relief for validation during various phases of a software project. This improves communication among coders, designers and product owners, and allows potential glitches to be immediately rectified. Test automation assures higher efficiency of the development team. Besides that the earlier a defect is identified, the more cost-effective it is to fix the glitch.

7. Testing efficiency improvement

Testing takes up a significant portion of the overall application development lifecycle. This goes to show that even the slightest improvement of the overall efficiency can make an enormous difference to the overall timeframe of the project. Although the setup time takes longer initially, automated tests eventually take up a significantly lesser amount of time. They can be run virtually unattended, leaving the results to be monitored towards the end of the process.

8. Reusability of automated tests

Due to the repetitive nature of test automation test cases, in addition to the relatively easy configuration of their setup, software developers have the opportunity to assess program reaction. Automated test cases are reusable and can hence be utilized through different approaches.

9. Thoroughness in testing

Testers tend to have different testing approaches, and their focus areas could vary due to their exposure and expertise. With the inclusion of automation, there is a guaranteed focus on all areas of testing, thereby assuring best possible quality.

10. Faster time-to-market

Test automation greatly helps reduce the time-to-market of an application by allowing continuous delivery. See Test Automation and Automated Tests.

11. Improved information security

The effectiveness of testing will be largely dependent on the quality of the test data you use. Manually creating quality test data takes time and as a result, testing is often performed on copies of live databases. Automation solutions can help with creating, manipulating and protecting your test database, allowing you to re-use your data time and again.

12. Ability to do full regression testing each deployment 

With short cycles, manual regression testing is nearly impossible. Iterative and incremental development implies that code is not frozen at the end of the iteration but instead has the potential to be changed each iteration. Therefore, manual regression testing would mean rerunning most of the manual test–every iteration. Automating the tests therefore pays back quickly.

Read more…