Skip to main content

Author: Martin Fenelon

PMTimes_Sep03_2024

Managing Software Testing

Written by Martin Fenelon on . Posted in Articles.

You cannot test quality into software.

Some project managers make the mistake of stepping back when software testing takes the forefront in their projects.

 

It may be due to a lack of hands-on testing experience, concerns over the increasingly technical nature of software testing, or a willingness to let the QA Lead drive the bus for a short period. None of these reasons are valid. Regardless of their roles prior to becoming PMs, they can and should continue to lead the team during testing. In the next few articles, we’ll focus on helping PMs better understand how to guide their teams to delivering better software. Testing the software is just one part of that journey.

 

Let’s clear up some misperceptions. The purpose of testing is not to attempt to break the software, nor to find every possible defect, but to demonstrate that the software will fulfill its intended purpose with a reasonable level of confidence. As highlighted by the quote above, software quality must be built into the project and development process from the beginning rather than being added through testing. Testing allows us to confirm that the expected quality is there and to find and correct those places where it is not. Remember the definition of software quality that we are using:

 

Quality code is code that in order of importance, does what it is supposed to do, is bug free, and is well-crafted.

– Stephen Vance

 

The Institute of Electrical and Electronic Engineers (IEEE) definitions for verification and validation apply during this project phase, so their formal definitions may inform discussions about software performance under testing.

  • Verification: The determination by objective, repeatable methods that an item satisfies its stated requirements.*

 

In other words, the software works as it is intended to work, and it meets the requirements it is connected to.

  • Validation: The determination by objective, repeatable methods that an item can be used for a specific purpose.*

 

In other words, the software is suitable for purpose, meaning the requirements correctly describe the business need that the software satisfies.

 

(*Adapted from The Project Manager’s Guide to Software Engineering’s Best Practices, by Mark J. Christensen and Richard H. Thayer, IEEE Computer Society Press, Los Alamitos, CA, 2001.)

 

Every test should be traced back to a requirement, either functional or non-functional. If we cannot trace a particular test back to a requirement, we need to question why that test is needed and what purpose it serves. To ensure that we are not wasting time with unnecessary tests and that we are performing the required tests in an appropriate manner and sequence, we start by developing a test strategy. The test strategy defines what will be tested, how it will be tested, and what results are needed to determine that the system is ready for production.

 

Advertisement
[widget id=”custom_html-68″]

 

Once the test strategy is established, one or more test plans are created to meet the goals of that strategy in a methodical, effective, and efficient manner. Test plans describe the purpose of the test, entry and exit conditions, and specifically where and how the system will be tested. Once we have test plans, we can dive into the detailed planning of each test or series of tests. This usually results in test cases, definitions of test environments or regions, test interfaces, test data, and so on.

 

While the project manager is not responsible for creating any of these documents or artifacts, they should be closely involved in their development, review, and ultimate approval. They will have a significant impact on the project schedule, including task duration, task sequencing, key gates, and their location in the schedule. Quality assurance and testing schedules must be coordinated with those of the other teams within the project and typically external to the project (for example, the infrastructure team). These, in turn, impact the budgets and resources that go into the project plan. There may be significant risks or issues that will need to be addressed via specific testing, such as a new external interface or a set of complex calculations, with solutions that must be clearly described in both the testing and overall project plans.

 

The project manager is not expected to be an expert in software testing design or execution, just as they are not expected to be software engineers. They are expected to be familiar with the role, purpose, and types of testing required by their project under the delivery methodology being followed. PMs should ask thoughtful questions, ensure open issues are properly resolved, and participate in walkthroughs of key quality assurance and testing deliverables. We’ll briefly go through common ones in the following sections. While PMs should not be the ones driving the team through testing, they need to ensure that it is being done and done effectively. Some tips on how to do this are covered below.

 

The key point to remember is to be proactive, not passive, with these deliverables and tasks. Although quality cannot be created by testing, testing should identify where quality is lacking so it can be improved. Thorough testing supported by appropriate metrics will find and eliminate most defects and improve confidence that the team is delivering a high-quality system. This section highlights key considerations and leverage points for PMs to help them get the best results possible. There are separate books, whitepapers, and training courses that go into software testing in greater depth. Don’t hesitate to refer to them if desired or if you encounter a particularly unique or difficult testing issue.

 

Next Up: Types of Software Testing

 

Concerned about all the news stories about significant software failures over the past few months? My upcoming book, Building Better Software is focused on providing Project Managers an easy-to-follow guide for successful software development projects.

 

PMTimes_Mar26_2024

Adapting Agile Principles for Successful Maintenance Hand-Overs

Written by Martin Fenelon on . Posted in Articles.

Over the 20+ years since the Agile Manifesto was created, more and more organizations see agility as key to success, especially for software development. Agile methodologies have revolutionized the way teams approach software development, emphasizing flexibility, collaboration, and continuous improvement. Ideally, there are Product Teams that handle development and maintenance throughout the product’s lifecycle. But what happens if development and maintenance are handled by separate teams?

This scenario can be problematic, especially if the teams are using are using different methodologies, or belong to different organizations (e.g. in-house and contractor teams). What happens when it’s time to transition control of a software project from the development team to the maintenance team? Can Agile principles be applied to facilitate successful hand-overs? In this article, we’ll explore how Agile principles can be adapted and applied to ensure smooth and successful software transitions.

 

Understanding Agile Principles

Before we delve into how Agile principles can be adapted for software transitions, let’s briefly review some the core principles of Agile methodology. Agile is built on four foundational values and twelve principles, as outlined in the Agile Manifesto. These values and principles emphasize:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan (flexibility)

 

Adapting Agile Principles for Transitions

Now, let’s examine how these Agile principles can be adapted and applied to facilitate successful software transitions:

  1. Flexibility: Agile methodologies prioritize flexibility and adaptability, allowing teams to respond to changing requirements and priorities. Similarly, in software transitions, flexibility is one key to navigating unforeseen challenges and adjusting plans as needed. By adopting a mindset embracing change, teams can proactively address issues and adapt their approach to ensure a smooth transition.
  2. Collaboration: Collaboration is a cornerstone of Agile methodologies, with teams working closely together to deliver value to customers. In the context of software transitions, collaboration between the development and maintenance teams is essential for success. By fostering open communication, sharing knowledge, and working collaboratively to address challenges, teams can ensure a seamless hand-over process.
  3. Continuous Improvement: Agile methodologies also emphasize continuous improvement, with teams regularly reflecting on their processes and seeking ways to enhance efficiency and effectiveness. Similarly, in software transitions, teams should evaluate their transition processes, identify areas for improvement, and implement iterative changes to optimize the hand-over process over time.

 

Advertisement
[widget id=”custom_html-68″]

 

Applying Agile Practices to Transitions

In addition to adapting Agile principles, teams can also apply specific Agile practices to facilitate successful software transitions. Some key Agile practices that can be applied include:

  1. Iterative Planning: Adopting an iterative planning approach to break down the transition process into manageable iterations, with regular checkpoints to assess progress and adjust plans as needed.
  2. Daily Stand-Ups: During the transition period consider holding daily stand-up meetings, where team members share updates, discuss progress, and identify any impediments. The goals is to facilitate communication and alignment between the development and maintenance teams.
  3. User Stories: Creating user stories to capture requirements and priorities from the perspective of the maintenance team can help ensure that the transition process is aligned with the needs of the end-users. Even more importantly, user stories that include updating and maintaining the software and likely rule or data updates will improve the maintainability of the software itself.
  4. Retrospectives: Conducting retrospectives at key milestones during the transition process allows teams to reflect on their experiences, identify successes and challenges, and brainstorm improvements for future transitions. These should also be communicated across teams and product groups.

 

Applying Agile Principles in a Software Transition

To illustrate the application of Agile principles in software transitions, let’s consider a hypothetical case study of a software development company transitioning control of a web application from the development team to the maintenance team:

  1. Flexibility: When unforeseen technical challenges arose during the transition process, the development and maintenance teams collaborated to adjust their plans and implement creative solutions, ensuring a successful hand-over despite the challenges. This included adjusting target dates and budgets for both teams to provide the time and resources needed.
  2. Collaboration: Through regular stand-up meetings and collaborative planning sessions, the development and maintenance teams worked closely together to share knowledge, address issues, and ensure alignment throughout the transition process.
  3. Continuous Improvement: Following each milestone in the transition process, the teams conducted retrospectives to reflect on their experiences and identify opportunities for improvement. By implementing iterative changes based on these retrospectives, the teams continuously optimized their transition processes over time. These were shared with other teams, along with tools, templates, and tips that had proven useful during the transition.

 

Conclusion

In conclusion, Agile principles can be effectively adapted and applied to facilitate successful software transitions from development to maintenance. By embracing flexibility, collaboration, and continuous improvement, teams can navigate the complexities of transition processes with confidence and ensure a seamless hand-over that meets the needs of end-users. Through the application of specific Agile practices and a commitment to Agile values and principles, organizations can optimize their transition processes and set the stage for long-term success in software maintenance.

If your organization uses Agile methodologies with development and maintenance handled by different teams, how are transitions handled?

PMTimes_May09_2023

Getting the Call to Action – Taking Over a Project

Written by Martin Fenelon on . Posted in Articles.

We usually don’t identify projects that we want to take over and make a request. Instead, we are identified as a candidate to assist or take over an ongoing project. How should we proceed?

 

Our goal is to quickly assess the current situation, focusing on the executive or management level, to help us decide if this is an opportunity that we should take or if we should steer clear. Even if we cannot decline the opportunity, the information gathered here will help us plan our first steps and should help us determine the extent of executive commitment to the project and the way to improve it.

 

The most critical question to ask is, “Why are we changing the PM now?” The PM may have been moved to a more important assignment, transferred to a different position as part of their career growth, or may just be on extended leave. If one of these is the reason given, there may still be some challenges in taking over the project, but there aren’t any warning signs yet.

 

There may be answers that raise warning flags, such as “We just fired the PM.” Or “The PM quit unexpectedly.” These usually indicate a project with issues. Another red flag warning is when the customer (internal or external) has demanded a change in the PM. While this may just be a style or personality conflict between the individuals, there are often deeper issues.

 

Carefully consider the responses you’ve received to this first question before proceeding. Is this shaping up as a situation where you will be the next PM being replaced, potentially harming your professional reputation and career? Do there appear to be political games being played? If so, do you want to join the game? If you have to take the assignment, what precautions are needed?

 

The next question for the Project Sponsor and Business Owner, is “What does success look like?” If they cannot succinctly describe this, how can the project be successful? Even under Agile or Flow Methodologies, “do good stuff” is never enough guidance. All projects have objectives. While they may be modified through the course of the project (being “agile”), at any given point in time the current objective must be clear and understood by all the stakeholders. If you cannot establish a clear response to this question, this issue must be flagged.

 

A more difficult question to get a true answer to is, “What is the current status of the project?” The true status may not be known, and different stakeholders are likely to hold different views. At this stage, we want to determine what views are held by the key stakeholders. If negative views are expressed, this is an ideal time to lay the foundation for future requests for help or support.

 

If there seems to be a consensus that the project is challenged or adrift, an immediate follow-up question needs to be asked: “Should this project be terminated?” Get this option on the table to save a lot of time and effort later. We are not recommending that the project be terminated, though we may do so later after we’ve done a thorough review. We are reminding the executive team that this is an option they should be considering if they haven’t already done so.

 

If the decision is made to continue the next question is, “If it is not on track, what caused it to go off track?” We will get into the actual reasons as part of our project review later on. At this point, we want to discover the executive view. Do not assume that this initial view is 100% true, there are probably some facts that support it.

The remaining questions are focused on executive commitment to the project and our accepting the opportunity to join as the PM. They will lay the foundation for the next steps that you will take as you assume leadership of the project team.

 

We need to learn, “Why was I selected for this project?” The goal is to learn more about the project and why they are coming to you to take over. Is it just because you are available? Do you have specific skills and experience that they think are needed, or something else?

 

Advertisement
[widget id=”custom_html-68″]

 

Next, ask “What do you need from me to help this project succeed?” Essentially a follow-up to the previous question, we are identifying the knowledge, skills, time, and commitment that they expect us to bring to the project. Is the intent for us to carry the project through to completion? If the answer is no, follow up with, “What is the desired project status to trigger my transition out?” These answers will impact your plans for assuming responsibility for the project and how you will be viewed by both management and the delivery team.

 

The next two questions can indicate the likelihood of success. “What authority will I have over the project team? Over external teams or resources that we need to succeed?” A common problem with modern organizations is dispersed authority. Being responsible for a successful outcome without having commensurate authority over the resources and teams is not only difficult, it is a recipe for frustration and disappointment. Uncover any potential issues of this kind now, and be prepared to discuss why the organizational arrangements need to be changed.

 

Ask your manager, the Project Sponsor, and the Business Owner, “What will you do to help this project succeed?” If they appear indifferent or show a lack of commitment to project success, this is a clear sign that the project is unlikely to succeed. Be very careful about boarding the Titanic while the captain is eyeing the lifeboat.

 

Finally ask “Do I have the option to turn down this assignment?” The answer may be yes, in which case you need to decide based on your career goals, your current personal situation, and everything you’ve learned about the project to this point. If you decide to accept the opportunity, do so with the firm intention to do your best and to be fully committed to a successful outcome for the organization, the project, and the project team.

 

If the answer is that you have to take the assignment, be professional about it. This may be a good opportunity to request specific things you need to be successful—key personnel; increased authority; ability to request scope, schedule, and budget changes later; etc. Explain that you are going to do a thorough project review and discuss the results with the key stakeholders. That discussion may include recommendations for them to consider, including additional support. Set the groundwork for your review and that follow-up meeting, indicating that you cannot promise a successful project outcome before then.

 

For a more detailed discussion of how to handle a request to take over a project, see my book:  There’s A New Sheriff In Town: The Project Manager’s Proven Guide To Successfully Taking Over Ongoing Projects And Getting The Work Done , Fenelon, Martin J., eBook – Amazon.com

 

11 Questions to Ask Before Taking Over a Project

1.     Why are we changing the PM now?

2.     What does success look like?

3.     What is the current status of the project?

4.     If it is not on track, what caused it to go off track?

5.     Why was I selected for this project?

6.     What do you need from me to help this project succeed?

7.     Do you intend for me to stay as PM through the end of the project? If not, what is the desired project status to trigger my transition out?

8.     What authority will I have over the project team?

9.     What authority will I have over external teams or resources that we need to succeed?

10.  What will you do to help this project succeed?

11.  Do I have the option to turn down this assignment?

 

PMTimes_Mar28_2023

Potential Challenges With Ongoing Projects

Written by Martin Fenelon on . Posted in Articles.

When joining a project that has already started or when tasked to review an existing project, a Project Manager is faced with a number of challenges. These primarily relate to not having been with the project team from the beginning and, therefore, not having been part of the planning process. As noted in a prior article, scope, schedule, and budget are probably already set. Many other decisions have also been made, some explicit, some implicit. This leads to the first challenge that the new PM has—what is the true status of the project? We’ll describe how to determine the true status of the project in more detail in a future article, along with providing some useful tools. Before going there, we should look at potential challenges that arise because a change in PM is contemplated or occurring. These challenges or issues will be added to those that already exist in the project and will also need to be addressed as part of the takeover and recovery plan.

 

There are many reasons for another PM taking over a project, and the project itself may not be in trouble; it may truly be in “Green” status. While that is great and makes things easier for the incoming PM, there are still challenges tied to the change in management that must be dealt with. Let’s review a few of these.

 

First, the previous PM may no longer be available. They may have left the organization, be out on extended personal leave, been moved to a different project, and not available for a hand-off, etc. This means the incoming PM is unlikely to have access to all the information that the previous PM had, especially around the reasons why certain decisions were made. For example, why was the delivery broken into three increments? Why are there four Scrum Teams instead of three? While interviewing the Business Owner (BO), Sponsor, Customer, and delivery team should provide some insights, if we can’t talk to the previous PM directly, we are unlikely to know why they made the decisions that they did.

 

Second, at the opposite end of the spectrum, the former PM may still be around, perhaps due to subject matter or technical expertise. Since they are still part of the delivery team, there are likely to be team and political issues with them no longer being in charge. The incoming PM needs to understand the reasons for the change and the decision to keep the former PM on the team. Specific actions will be needed to reduce any team or political fallout from the change and to ensure that the team continues to move forward as a team.

 

Advertisement
[widget id=”custom_html-68″]

 

Another challenge can arise if the Sponsor, Business Owner, or Customer change at the same time as the PM. Or if one is assessing a project due to a Business Owner change and a project review is requested. There have been cases where a successful Business Owner and PM that work well together are moved to higher priority programs or projects, especially if the current project is going well. This adds to the existing incoming PM challenge of building a relationship with the new Business Owner and rebuilding the team dynamic. Many Business Owners joining a project want to review prior decisions, change requirements and agreements, and potentially alter the goals of the project, all to mold the project to meet their goals and add their personal stamp onto the project. While this is a natural human reaction, it can be deadly in a project. The incoming PM needs to hold the line and minimize the disruption to the project, often without a full understanding of the rationale behind decisions already made. This is difficult to do, even while promising to look further into issues raised by the Business Owner. Diplomacy and firmness are both needed to avoid unnecessarily impacting the project.

 

Of course, there can be non-political challenges as well. When Project Managers discuss situations that they have found when assuming leadership of a project, it is striking how different they are from starting a new project. One of the key differences is that the ongoing project may already show evidence of problems, or have challenges. We’ve listed some common project challenges and possible causes in the table below. The challenges identified when a new PM is being asked to take over a project will influence the initial steps in assuming command, and should be discussed with management as part of accepting the new assignment. We’ll cover how to handle this in upcoming articles.

 

 

As you can see in the table, many challenges (symptoms) can result from similar causes and be related to multiple issues. It is important to avoid jumping to conclusions or developing action plans before getting to the real causes of the challenges. Future articles will describe the how to get to the root causes and ways to address them. In the meantime, how would you assess the true status of a project that you are joining?

 

For more information on how to handle this situation, and a guide for taking over an in-flight project, please check out my book on the topic. There’s a New Sheriff in Town: The Project Manager’s Proven Guide to Taking Over Ongoing Projects and Getting the Work Done. https://www.amazon.com/Theres-New-Sheriff-Town-Successfully/dp/B0BMJ4J7GL

PMTimes_Feb21_2023

We Don’t Always Start Fresh

Written by Martin Fenelon on . Posted in Articles.

Project Management texts usually assume we’re starting at the beginning of a project, with control over scope, schedule, and resources. Frequently, project scope, resources, and schedule are already determined through strategic planning, Project Portfolio Management (PPM), or the project charter process. In other cases, we take on projects that are in progress. This can occur as a normal part of the project lifecycle as a hand-off from a project initiation team to a project delivery team or due to other circumstances. The existing Project Manager (PM) may be moving to a different, higher priority project, assuming other responsibilities within the organization, leaving the organization for other career opportunities, or leaving the project due to the problems that have arisen. In all these cases, the new PM is required to assess the current status of the project, update or create a plan leading to a successful conclusion of the project, and execute that plan through project completion.

 

There are specific things that a PM can do to improve their chances of successfully completing the ongoing project, regardless of its current state or delivery phase. While these will be covered in future articles, and in my book, There’s a New Sheriff in Town: The Project Manager’s Proven Guide to Successfully Taking Over Ongoing Projects and Getting the Work Done, in this article we will examine how likely it is for a PM to step into an ongoing project.

 

Assuming management of an ongoing project is a lot more common than many people think. All the PMs that I’ve met over the years, through work, at conferences, and online, have taken over projects that were already started. Industry results and surveys also show that the overwhelming majority of PMs have had to assume projects or programs that were already in flight. Close to 200 project managers responded in 2022 to an online global survey on their experience with joining projects that had already been started.

 

PMs are much more likely to take over existing projects than to start with a “clean slate.”

 

Roughly 93% of the PMs responding have had to take over a project that was already started at least once in their careers. There are significant differences and additional challenges when taking over projects that have already started. Despite these circumstances being very common, they are not routine and should not be treated as such. We need to recognize the challenges of joining a project that has already started, along with the typical challenges of managing projects.

 

How frequently does this happen?

 

Two-thirds (67%) of all the projects managed by these PMs had a different PM when they finished.

 

Far from being a rare occurrence, we should assume that most projects will have a change in leadership before they finish. How many PMs plan to hand over leadership to another PM? All too often, we assume that we will finish what we start, so if a change in leadership does occur, we are not prepared for it. Whether we are handing off the project to another PM, or if we are the incoming PM, the hand-off will be more challenging and less successful if we are not prepared for it.

 

Advertisement
[widget id=”custom_html-68″]

 

Why is assuming management of an ongoing project different than starting a new project? Table 1-1 provides a brief listing of project characteristics, components, and key management decisions that are still being formulated when a project is initiated but are usually set once a project has started. We’ll discuss some of these issues, and how to handle them as an incoming PM, in future articles.

 

Table 1-1: New Projects Versus Ongoing Projects

COMPONENT NEW PROJECT ONGOING PROJECT
Objectives Loosely Defined Established
Scope/Requirements Being Determined Preliminary or Approved
Quality Being Negotiated Defined
Schedule Being Negotiated Set
Budget Rough Order of Magnitude (ROM) Set
Delivery Method Candidates identified Chosen
Technology May be defined, flexibility will vary Selected
Delivery Team Being Selected Created and working
Delivery Location May be open Set
Delivery Tools Being determined based on technology and delivery methodology selected In Use
Project Plans Being Drafted Published and Approved

 

The results of the survey, discussions with PMs across the globe, and personal experience have all shown that we don’t always start on a project with a clean slate where we can work with the sponsor and business owner to establish the triple constraints. In fact, it is almost guaranteed that during our PM careers we will have to take over an ongoing project. The bad news is that this can be very different from initiating a project, with additional challenges that make it hard to succeed. The good news is that we are not alone in facing these challenges, and that there are proven techniques that greatly increase the likelihood of success. In addition to covering these in my book, we will address many of them in future articles.