Wednesday, March 14, 2018

The five 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. 


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.


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…

Tuesday, March 13, 2018

8 Benefits of working with an external project recovery consultant

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 organisation, our way of working, our project, etc. While this is mostly true there are a number of benefits that can tip the scale in favour of working with an external consultant on a project recovery. Here are eight of them:

1) The project recovery consultant 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 consultant 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 lot's of experience with.

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

4) It is common for consultants 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) Consultants 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 a consultant 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, a consultant 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, cancelling contracts, or removing team members. Often these actions result in lingering animosity. By using a consultant 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.


Selecting the right consultant 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 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…

Monday, March 12, 2018

The 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 - Sponsors, Change Teams, Reference Groups and Users.

1) Sponsors (or project owners) 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 change project accordingly.
2) Project Teams 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 Groups 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.

So 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.

So why should we do this?

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

- 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).

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.

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

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.

- 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 less 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:

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.

Read more…

Sunday, March 11, 2018

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!

So 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 co-ordinated 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.

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.

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.

Read more…

Saturday, March 10, 2018

Project Recovery - Halting the project

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. 

Why is it necessary to halt the project? 

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…

Thursday, March 08, 2018

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…

Wednesday, March 07, 2018

Test Automation and Automated Tests

Because of my work as project recovery consultant, I talk a lot about testing, continuous integration, continuous delivery, continuous deployment, and DevOps. During these conversations, the term automation gets thrown around in abandunce.

In general, we all understand what automation means - the use of some technology to complete a task that was done manually before. But when we talk about automation in terms of testing, there are some nuances that we have to make.

Two types of automation

In the world of testing in general, and continuous delivery in particular, there are two types of automation:

1) Automated Tests
2) Test Automation

While it might just seem like two different ways to say the same thing, these terms actually have very different meanings.

Automated tests are tests that can be run automated, often developed in a programming language. In this case, we talk about the individual test cases, either unit-tests, integration/service, performance tests, end-2-end tests or acceptance tests.

Test automation is a broader concept and includes automated tests. From my perspective it should be about the full automation of test cycles from check-in up-to deployment. Also called continuous testing.

Some linguistic analysis might also help clarify:

Automated Tests - in this case, "Tests" is a noun; the test is a thing. "Automated Tests" are particular types of tests; ones whose execution has been automated via some kind of code so that a person does not have to manually execute the test. You can have 1, 2, 3.... hundreds of automated tests.

Test Automation - this can be a noun as in the subject of "Automation" with "Test" indicating the type of automation. But, it is also referring to an activity; the activity of automating a given test or set of tests. As said previously; "Test Automation" is a broader concept than "Automated Tests".

Both automated testing and test automation are important to continuous delivery, but it's really the latter that makes continuous delivery of a high quality even possible.

Essential for continuous delivery

In a traditional environment, testing gets completed at the end of a development cycle. But as more and more companies move toward a DevOps and continuous delivery model in which software is constantly in development and must always be deployment-ready, leaving testing until the end no longer works. That's where continuous testing comes in - to ensure quality at every stage of development.

While ensuring quality at all times is very important, it's not all that counts. The speed at which all of the integration and testing occurs is very important as well. That's because if something in the pipeline stalls or breaks down, it holds up everything else and slows down the release of new developments, which defeats the purpose of continuous delivery.

This "how" and "why" make organization, consistency and speed imperative to support a continuous delivery model, and that's where test automation can help.

How automated test and test automation help

Managing all of the testing needs in a continuous delivery environment is a massive undertaking - it requires a tremendous communication effort to keep track of which environments have deployed new code, when each piece needs testing and how those requirements integrate back into the moving process of continuously delivering software. A simple continuous delivery pipeline could look like this:

1) Continuous integration server picks-up changes in the source code
2) Starts running the unit-tests
3) Deploys (automated) to an integration environment
4) Runs automated integration tests
5) Deploys (automated) to an acceptance environment
6) Runs automated acceptance tests
7) Deploys (automated or manual) to production

This is a combination of making automated tests by developers or testing engineers and DevOps people automating deployment. In doing so, test automation goes a long way toward helping ensure that teams maintain a high standard of quality at all points along the pipeline.

Read more…

Monday, February 19, 2018

Project portfolio throughput

Too many organizations try to save money on projects (cost efficiency) when the benefits of completing the project earlier far outweigh the potential cost savings.

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 (see "Cost of delay").

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. 

An important goal of your project portfolio management strategy should be to have a high throughput. Get projects delivered fast so you start reaping your benefits, and your organization is freed up for new projects to deliver additional benefits.

For a typical organization this means three things;

1) Doing fewer projects (in parallel). On average only half of what you are doing now.
2) Focus on doing the right projects.
3) Focus on improving your project delivery capability.

Read more…