Is formal project management necessary to successfully deliver a software project?  The short answer to that is no.  Many successful software products have been launched without any project plans or schedules, at least not in the traditional sense.  When I first started in this field, project plans were not the norm, but that was when programs fit in a device with less than one megabyte of memory. 

History

Things were different 20 years ago.  When I purchased my first 512 Megabyte hard drive, I thought that it was all I would ever need. Now I have over a terabyte of hard drive capacity, and it’s not enough.  However, one thing has changed: it’s the data that’s driving the secondary storage requirement today and not the requirement to install programs.

The software development teams were much smaller then too.  While I have anecdotal knowledge, a typical project team size was five or less software engineers in my experience. Some were bigger but not much bigger, and still fewer were even much bigger.

Software engineers had more responsibility: they created the functional requirements, created the designs, create the code, made the builds, created the test harnesses, created the test designs, executed the tests, packaged the software for release, wrote the user documentation, and supported the product.  This was the practice even in some large companies.

Present

Things have changed significantly.  Most applications today cannot execute in less than one megabyte of RAM.  The hard drive capacity common in the early 1990′s couldn’t support the install of Windows Vista.  The size of the teams has grown.  It’s difficult for me to say what a typical team size is today, but teams I have managed over the past  five years ranged from twenty team members to a couple of hundred, and instead of team members being collocated in a single office, the team members are located across the globe.  

Less Formalism

It’s possible to manage a team successfully without formal project management practices when the team and application are small, much like the typical project in the late 80′s and early 90′s.   If you think about it, how much logic could you create for a machine with a memory capacity of 640K and no virtual memory?   And if you were building embedded applications back then, the onboard memory capacity was typically significantly less. 

Teams were smaller because we were building less sophisticated applications, and we were building less sophisticated applications because the technology was less capable than today.  With smaller teams and smaller deliveries, a good manager could easily and successfully lead the delivery of an application without many of the formal project management practices. 

More Formalism

Today, project deliveries are much bigger than they were 20 years ago.  Team members are spread across the globe.  Applications are more complicated today.  For example, web applications are typically multi-tiered and distributed across machines; in addition, many different software technologies are used in one application: C#, SQL, HTML, .NET, AJAX, etc… Consequently, more formalism is required to manage these projects to deliver them successfully because the teams have gotten larger and more complex.

Why Plan

However, some professionals in the industry would still ask why should we manage with a formal plan?  Too much changes, and any plan is shortly stale after it is written.  Some would also say that it’s impossible to estimate a project successfully as estimates are always inaccurate, so any schedule is going to be wrong from the start.  However, these are precisely the reason to formalize planning.  

One of the key benefits of a project schedule is that it’s a tool, the only tool, to manage project change successfully.  The process of project management is essentially the process of creating a schedule, executing the plan, testing your estimating assumptions, and taking corrective actions when you learn that your estimating assumptions are incorrect. 

Without having that baseline view, there is no way to know that your project will not deliver on its commitments until it’s too late to take corrective actions.  A skilled manager is able to deliver on time even though the initial schedule proves to be inaccurate because they use the schedule as an effective tool for managing change.

If the schedule that you end your project with is identical to the schedule that you started with, then you were not managing your project.  Successful project management is the process of managing change and taking corrective actions when change is identified.  Change is reflected in the project schedule with either new tasks or original tasks reprioritized or ending earlier or later than scheduled. The inevitability of change is a reason to plan.  Consider these quotes.

“No battle plan ever survives contact with the enemy.”
–Field Marshall Helmuth Carl Bernard von Moltke

 
In preparing for battle I have always found that plans are useless, but planning is indispensable.”
– Dwight Eisenhower

Both quotes affirm that change is inevitable and that nothing goes as planned, but Eisenhower’s quote says something further: “planning is indispensable.”  He’s confirming that the process of project management is the source of its power.  The power is identifying what went wrong and taking corrective action.   It’s identifying what when right or better than expected and redeploying those resources to the highest priority needs.  You can’t do that if you don’t have a baseline plan, and you can’t take corrective action if you never assess how you are progressing to the plan.   Planning is indispensable.

Summary

Project management is a continuous process of planning, executing, measuring, and re-planning.  It’s the process of meeting your commitments in spite of all the change and obstacles along the way.   It’s a tool for managing change and complexity.  It’s hard, and because some aren’t successful with it or don’t do it well, it doesn’t mean that project management is not valuable.  Sometimes we blame poor execution on the process or the tools, but too often in software management it’s the skill that is at fault.  The difference between the 300 Avg. batter in baseball and the 200 Avg. batter isn’t the bat, the ball, or the rules of the game, it’s the skill of the batter.  If we can focus on the skill rather than debate the need for the tools, in this case project management, we can progress the practice of software management to higher levels because skills can be improved with practice and education.

References

A number of months ago I stumbled on the blog Herding Cats authored by Glen B. Alleman.  He authors a great blog on project management, and I consider him an expert in the practice of Project Management.  Many of his essays are provocative and insightful.  I highly recommend that you visit his site regularly for his perspectives on project management.  Here’s a link to one of his essays: Simple Conditions for Project Success.

Why does it take so long to deliver software products? Many stakeholders ask this question during the course of a software development project.  It’s interesting when the developers ask this question because they know what it takes to implement the functionality in software, but in asking that question, some in the organization often fail to appreciate what it takes to deliver a commercial product to market.  From one perspective, they are correct; it shouldn’t take so long, but from a different perspective, the long duration is understandable — even if undesirable.  I’d like to explore the perspectives that explain these differences using a hypothetical delivery.

Example Requirements

You are asked to build an application that will copy files created for the day from your systems to your customer’s systems.  The files need to be converted into a format acceptable to the customer’s application.  Every night the files generated for the day are copied using the FTP protocol to the customer’s FTP server.  The transfer must complete within two hours.  The communication from your systems to the customer’s will be via VPN over the internet.

Why So Long

This should take a couple of weeks at most — maybe even a couple of days. To convert the files, identify an off the shelf library that will convert between the two file types, and to transfer the files, also identify an off the shelf FTP library to transmit the files.  If there’s good public domain software, use that.  To complete the application, identify the files to transfer, call the method(s) to convert the file, and then call the method(s) to transmit the file. Repeat this until all the files are transmitted.

This is reasonably simple.  It shouldn’t take too long to write.  So why may it take a couple of months to deliver this application?  A college student could probably complete this application in a day.

Why It Takes Longer

The algorithm above works in the ideal case, but errors can arise that need to be handled gracefully.   Connecting to the FTP server may fail.  There may be errors in transmission.  Maybe there’s not enough space left on the destination server to transmit all the files.  These are a few of the possible errors that can surface during operation.  At a minimum, the application needs to detect these errors and report on them.

The entire operation needs to complete in two hours.  This requires that the algorithms to convert the files are efficient.  Some analysis is required to assess whether the third party libraries will be efficient enough to complete the work in time.  Depending on the findings, there may be more design work required to meet the applications performance requirements.

The application has to be supported when it goes operational.  Documentation needs to be created for the operations staff to support the application when it goes live.   When errors happen, the operations staff needs to know the procedures for identifying and correcting the various types of errors.  This is necessary if the developers don’t want to be called in the middle of the night every time the application fails.

There’s a dependency to address for this application before it can go operational.  A VPN connection needs to be configured between your site and the customer’s site.  While this isn’t a difficult configuration to set, the network operations team has a large queue of work, and it will take some time for them to get to this task.

The third party libraries need to be purchased.  This requires identifying and evaluating the products, submitting a purchase requisition, placing the order, and waiting for the software to be delivered.   Just these steps alone can take a couple of weeks.  If the software is unavailable for download, this will be a dependency since coding cannot complete until the software is in your hands and installed.

End-to-end testing needs to complete with the customer’s application that consumes the files transferred.  In the ideal case, it’s a day or less of work if everything works well, but if not, analysis and troubleshooting are required to find and correct the problems.

Summary

Too often when stakeholders ask the question, why it takes so long, they naively look at the feature to deliver and rightly conclude it can be completed quickly.  However, there are more requirements to address than the simple algorithm that delivers the primary functionality.  Not only does the application need to work in the ideal case, it needs to handle error conditions correctly.  Performance requirements must be addressed, and depending on the variables, this can add significant development overhead.  There are support requirements and network configuration requirements, which contribute additional overhead to the assignment, as well. 

Many of the requirements that add to the project duration aren’t visible to the stakeholders asking the question, and consequently, they aren’t calculated in their optimistic view of when the assignment should finish.  So if you are still asking why it takes so long, it’s only and FTP application.  What aforementioned aspects of this assignment would you leave out?  Usually, there’s a good reason it takes longer than we’d like and even expect.

Purpose 

To clarify some possible misconceptions about the goal of this article series, it is NOT to advocate that there should be unrealistic schedules.  Quite the contrary, I don’t support expecting a team to deliver herculean efforts.  It’s an unsustainable model.  However, dates and requirements are often forced upon software teams, and they often have little ability to influence the commitments, both in date and content.  The goal of this series is to outline a model to successfully manage through these challenging circumstances for the benefit of the company, the team, and yourself.

Risk Management 

To manage this project successfully one model is to approach this project as an exercise in risk management.   The risk is the team will be unable to deliver the project sponsor’s complete set of requirements on the commitment date, and in an attempt to completely satisfy those commitments the team will likely deliver much later and with lower quality than is required for success.  The steps outlined in part 2 of the series essentially identify a contingency and mitigation plan for managing this risk.

Contingency Plan

The contingency plan is to identify the most important requirements that can be successfully delivered on the commitment date (Steps 1 and 2).  Believing the odds are highly against delivering the complete set of requirements successfully, you identify a set of requirements that you can successfully deliver by the commitment date.  Solicit the support of the project sponsors to identify the prioritized requirements for the release.

If you are unable to successfully enlist the support of the project sponsor’s in prioritizing the requirements, you will need to do this on your own.  With the domain knowledge that you already have, view the product from a user’s point of view and prioritize the requirements from that perspective.  While it won’t be perfect, you will likely identify many of the most important features.  If you’re fortunate enough to have customer contacts, ask them for input.  Once you’ve done that, it would be helpfully to review your prioritization with the most experienced members of your team and revise the prioritization based on their input.

Mitigation Strategy

The best way to manage a risk is to prevent it from happening in the first place.  A majority of the steps outlined in Part 2 of the series is about risk mitigation. 

The first mitigation strategy is to make sure the requirements are well understood before implementation begins (step 3).  Review the requirements with the team to ensure there is sufficient detail and understanding for the team to implement the features successfully.  Much time is wasted on projects when developers don’t have adequate understanding and detail of the requirements.  If some requirements are detailed adequately to begin design and code, start the assignee on that work immediately.  I’m not suggesting everything needs to be understood before you start the implementation, but I am recommending that you don’t start the implementation for any feature where the requirements are incomplete or where the detail is insufficient. 

The second mitigation strategy is to get it right the first time (steps 3, 5 and 6).  This is supported by up front designs and reviews.  Some methodologies in practice today promote the idea that it is impossible to get designs right up front and promote constant refactoring as an approach to arriving at an optimal design.  This is not my experience at all.  I’ve seen wonderful designs that were implemented from an upfront conceptual approach, and they lasted for many years and supported many successful iterations of the product without change.  A poorly architected system is a drag on productivity.  Refactoring as a design approach is costly and consumes too much time.

The third mitigation strategy is to create a productive work environment (steps 4, 7, and 8).  Create a culture that is solution oriented.  The team views problems as challenges to be solved rather than events to fear.  Every worthwhile software project that releases surmounts many technical challenges.  Surmounting technical obstacles is what software development is all about, and it is part of the fun.  When technical challenges are accepted as natural, it promotes an environment of collaboration and support.  Team members collaborating and supporting each other will promote better and quicker solutions.

The fourth mitigation is to promote high quality (Steps 6 and 8).  Software development is tedious and error prone, and consequently, defects are unavoidable.  It is far healthier and more productive for the team to view defects as problems to be solved rather than events to be feared.  While it is possible that too many defects could derail the delivery, it is more important to release the project with high quality.  Identify release criterion that promotes high quality.  When a product is released with low quality, the next project begins day one behind the Eight Ball.  That needs to be avoided.

The fifth mitigation is to be proactive in your management (steps 9, 10, and 11).   Identifying problems early allows the team to find solutions without impacting the release date.   If some features are progressing slowly, it may be because the assignee is struggling with the implementation.  If you identify that early, you can help them before it impacts the schedule.  It may be progress can be enhanced by adding one or more additional team members.  When you discover that early, you may have the opportunity to secure those team members in time to make a difference. 

Having weekly status meetings sets a pace for the delivery.  When team members are expected to show progress towards the schedule on a weekly basis, they tend to be more focused on the strategy, and they will typically demonstrate good progress.  The weekly status/tracking meeting reinforces what the important deliveries are to the team and their expected completion thereby improving the team’s chances of achieving milestones along the path to the release date.  A successful release is built upon a series of successful weeks.  Make sure every week is a success.  This is best achieved by meeting with your team and tracking the schedule weekly.

Summary

If your risk mitigation strategy is successful, you may have been successful in delivering upon all the commitments on the original release date while not burning out the team.  Often times the impossible becomes possible with good planning, good execution, and a disciplined approach, but even if you happen to be unsuccessful in delivering the complete set of commitments, you have put the team in a position of strength.  When you discover that you cannot meet the commitments as planned, you can offer the project sponsors some palatable options.  Assuming you secured the highest priority requirements, you can present three good options to the sponsors:

1. Release on the release date the highest priority commitments with a follow-up release a short time thereafter with the missed requirements.
2. Slip the release date to secure all or some of the missed requirements.
3. Re-prioritize the missed requirements that can still be delivered within the original release date and ship on the original release date.

While some project sponsors will be sorely disappointed with these options, it surely beats having nothing to deliver on the release date, and it is undoubtedly better than offering only one option: slip the release date as is often the case.   Over time you will build confidence in the management team for making good decisions, you will develop a reputation for reliable delivery, and consequently, as you build your reputation, you may find you are less pressured to deliver the impossible.

Management Approach

I’ve identified eleven tasks that I believe are essential for delivering to an unrealistic schedule.  While the tasks are numbered, they signify a loose priority.  It’s not intended for them to be followed exactly one after the other except for the first two.  The first two are the most important of the tasks, and the approach hinges on the first two for this to be successful.  When you’ve completed the first two tasks you’ve essentially identified your strategy.

1. Identify the feature priorities.  Hopefully the Product Manager will help identify them, but it is sometimes the case that they are unable to decide on the priorities.  If they don’t, you have no choice but to ascribe your own priorities to the features.  The best way to do this is to view the requirements from a user’s perspective.  As a user of the product what would you find most to least important. Accept that this isn’t perfect, but it’s better than having no priorities.
2. Now that you have the priorities identified, put a schedule together that will absolutely deliver the largest number of high priority features with high quality. This schedule will still be aggressive and people will still be required to work overtime, but it should be a comfortable pace.  This is your first iteration that you will deliver to test.  Schedule the remaining features to fit the time remaining as best you can – even time box them if you have to.
3. Review the requirements with the software team making sure there is sufficient detail to deliver the functionality as requested.  If the requirements need further detail, then assign requirements writing to the developer responsible for implementing each feature.  Divide this work up; it needs to be completed quickly.  Some teams have Systems Analysts or Business Analysts that perform this work.  Supplement them with your developers.
4. Don’t postpone solving difficult problems.  If you postpone the difficult problems you’re creating a train wreck.  Call a meeting with the right subject matter experts and begin solving the problem. There is no time to discover the problem is bigger than thought or the proposed architecture won’t accommodate a solution to the problem. Discovering and solving problems early and quickly enhances the team’s ability to deliver quickly.  I’ve found the greatest time waster on projects is when problems go unresolved seemingly forever.  Things like not having agreement on how a feature should work, or not having engineering agreement on an interface definition.  When closure takes too long, it slows people down and the backlog builds.
5. Do up front design and hold design reviews.  As the manager, participate in the reviews for the most complicated and/or important features.  For the others, make sure your top engineers are involved in those reviews.  There is no time to use re-factoring as a methodology for arriving at an optimal design.  You only have one shot at this. Make it your best shot.   At this point things are a little scary because time has lapsed and you have little working code to show for it.  Be patient.  This is an investment and good investments take a little time to show returns. 
6. In parallel to design, the QA team should be developing their test designs.  Include the QA team member in the design reviews for the features they will be writing test designs.  Assign to the developer implementing the feature the responsibility for making sure the test designs are thorough.  The QA person writing the test design should feel comfortable approaching that developer with questions. This developer is responsible for reviewing the QA test design.There are two reasons for this:  the developer is ultimately responsible for the quality of the delivery and this affirms that, and the developer writing the functionality will know more about the feature than the QA person.   There may be differences in opinion on how the feature is supposed to work.  This is good because waiting until test is not the time to find that out.  This is a team effort; there should be no mentality of throwing the build over the wall for test.
7. Create an environment of teamwork and be solution oriented.  You don’t want team members to fear bringing problems to your attention.  Out of site, out of mind is not a successful approach for delivering this project.  Eventually, hidden problems become visible tumors.  To avoid that, you need the team members to feel comfortable with bringing problems to your attention early.  Don’t solve the problems for them, unless they are ones only you can solve, help them to solve the problems for themselves.  The only bad problem is a problem without a solution and one that was withheld.
8. View identification of defects as positive events, even if you find a lot of them.  Each defect identified under test is one less problem discovered by your customers.  If you find lots of them, you’re customers probably won’t find many as there won’t be many for them left to find.  Anecdotally, I have found that the more defects found in test, the higher the quality of software when delivered to customers.  Taking this attitude removes unnecessary stress and anxiety from the team, and consequently, they will perform better.   Writing defects is unavoidable in software development. Everyone who writes code writes defects.  Focus positively on finding and fixing them — no matter how many found.  The focus should be on flow — making sure defects are fixed as fast or faster than they are found.
9. Practice management by walking around.  Don’t be a nuisance, but show genuine interest in what the team members are doing and how they are doing.  This has positive benefits to team morale.  Many managers today manage behind a closed door and communicate via emails.  Every team member I have talked to has disdain for this approach.  Do it under a tight schedule, and they do not respect you. You need the team’s respect to have them perform at optimal performance. Build relationships.  Taking the time to talk with people and to know what they are doing and the problems they are having in a sincerely interested manner says that you value them and that they are important.  That’s the message you want to send because it’s true.  You can’t send that message from behind a closed door.
10. Be disciplined about tracking the schedule; track the schedule weekly.  Preferably use metrics for tracking.  It’s the best approach for bringing objectivity and actionable indicators to the tracking process.   The reason this is so important is that early in the project time is on your side.  If you know how the project is progressing to the schedule more accurately, you can make decisions early enough to solve the problems and bring the delivery in on schedule.
11. When you’ve detected that the project will not deliver on schedule, determine what you need to do to change that and meet with the project sponsors to agree on a course of action. Determine the following: if more people will help to bring the project in on time, identify how many, what skills, which individuals, and for how long.  Identify the features you would need to remove from the project to bring it in on time: this should not include those high priority features identified in step 2.  Identify how much more time would be required to deliver the remaining features.  You have to have an estimate you are confident of nailing with good quality without skipping important steps like design, etc…

Summary

The goal of this approach is to develop a strategy, focus on solutions, identify problems early, focus on quality, use time wisely, be proactive, and encourage teamwork.  In the next and final installment, I will describe how this supports managing an unrealistic schedule successfully.

You’ve probably been there, working to deliver on one of those unrealistic schedules.  They all roughly follow the same trajectory.  The marketing team sponsors the next project with a must hit inflexible date, an inflexible set of must have requirements, and an inflexible fixed budget.  As the software manager responsible for delivering the release, you attempt to bring some reality to the situation, but you instantly conclude it is hopeless: there’s no changing your circumstances, and if you continue to try, it will only harm you. 

This is when many mangers make the fatal mistake: they immediately start the team coding.  There is no time to plan, no time to document, no time for meetings, no time for reviews, and no time for unit testing.  There is only time to code it, build it, pass it to QA for testing, find defects, and repeat the process until the release date. Then, someone makes a decision to either release it as is or slip the date and apply more pressure.

In this model the software manager has two primary responsibilities.  One responsibility is to apply more pressure on the team to work longer and harder.  The second responsibility is for the software manager to assume the role of fireman (hero):  wait for problems to surface, hold a meeting, give orders, and make decisions – hopefully good ones.

Once a project is in this mode and continues to work in this style, each release becomes ever more difficult to deliver as the code base becomes more fragile with every release.  Further complicating the situation is the high rate of team members exiting the company.   You’re losing your best and experienced people. You’re in the death spiral.  How do you fix it?

Prerequisites

To break the cycle, this product requires one manager with the authority, accountability, and responsibility for the success of the product delivery – a manager willing to make changes and consequently putting themself at risk for the good of the team and the product.  Working a team to the ground is often enough to keep your job even when things go wrong because it looks like you did everything to make a success of it, but it is really only show.  The team needs to work smarter and differently, and if you’re decisions don’t result in success, you will be the blame for it.  If you can’t handle that, well then nothing will change. 

It’s said a chain is only as strong as its weakest link.  In this role the software manager is that link.  The success of this delivery is dependent on the manager’s leadership as the manager sets the direction for the team and has the final say on all important decisions.  The manager is the only role with the depth and breadth of influence to affect the outcome measurably.

This manager needs to be responsible for both the Software team and the QA team.  Think of this like a football team.  There’s one head coach, and the head coach is ultimately accountable for the success of the team.  While there is an offensive and defensive coach, the head coach can overrule the decision of the subordinate coaches.  The head coach sets the strategic direction for the team.  He is the team leader.  Likewise, the software manager needs to be the ultimate team leader.

This manager needs both good technical skills and project management skills. The technical skills are required to know that problems are being solved appropriately, and if not, the manager needs to be able to mentor the team and provide technical direction.  There is no time to lose in making big technical errors, and the manager has the primary responsibility for preventing big technical errors. If this manager cannot assess whether solutions are appropriate to the problem domain then weak solutions will surface too late in the project lifecycle.  There simply is no time for late discovery of bad solutions that will adversely impact the delivery.

The lead manager needs excellent project management skills.  This manager should write and track the schedule.  The person who writes and tracks the schedule has the pulse of the delivery.   Having the pulse of the delivery is important because time is on your side early in the project, and with it, it permits you to make decisions early that will help secure the delivery.  The person who controls the schedule controls the team and secures the delivery.

I’m not suggesting there aren’t other important leaders on the team – there are.  The lines of command and control need to be clear and unambiguous for a difficult task to succeed. Like in a football game, the quarterback is the offensive leader on the field; the linebacker is the defensive leader on the field; the quarterback takes direction from the offensive coach; the linebacker takes direction from the defensive coach; finally everyone takes direction from the head coach.  Communication lines and responsibility is clear to everyone on the football team.  The software team requires similar leadership to get out of this jam.

Nobody has only one job responsibility on this team; any task required to deliver the project can be performed by anyone on the team.  If you need developers to test, then they put their QA hats on to test.  If you need them to write documents, then they write documents.  This is a team effort, and there is no room for prima donnas on a team – especially one that is delivering on a tight schedule.  If people are truly committed to team and teamwork, they should have no problem with this.  It helps to view our jobs a little differently in this environment.  Our jobs are bigger than software developer or QA tester.  Our job is to deliver a great product to market. In doing so, all the talents of the team may be required not just the talents narrowly defined by job titles.

Summary

A primary requirement for managing an unrealistic schedule successfully is good leadership.  Some organization structures are not well suited for managing through this problem successfully.  The PMO organization is often not well suited to managing through this problem domain as its decision making approach tends to be inefficient, and their often is a leadership void as the Project Manager often doesn’t have the authority to lead the team.  Further, team members are often working on multiple projects in a PMO structure, and fragmented attention adds further challenges to delivering on aggressive commitments.

Teamwork is also a very important requirement.  It’s the purest form of teamwork that’s necessary.  The kind that asks, “boss, what do you need me to do to help make this project a success?”  When you have great leadership paired with great teamwork, the impossible often becomes possible.

Does your final project schedule look identical to the project schedule that you began your release with?  If it does, you either aren’t managing your schedule or you are working on a dead product.  Project Management is predominantly an exercise in change management – so much so that I like to think of them as synonyms for one another. 

There are two primary sources of schedule change.  One source is when the actual productivity doesn’t match the budgets in your work break down structure.  The other source, the more problematic source of change, is when your requirements change.  This article will concentrate on managing changing requirements.

The Case for Change

No project develops as scheduled.  The schedule needs to change to reflect the new estimates and dependent consequences.  I’ve seen many software managers produce a detailed schedule during the planning phase only to never open the schedule again once the actual work begins.  That’s mismanagement.  This usually occurs when you have a technically oriented manager who undervalues what good management can bring to a project.  In my experience, these people are the source of more team problems than any other factor. 

A project with no requirements changes is either mismanaged or a dead project walking.  If the project you are delivering is something that has a future and the project stakeholders are excited and interested about, requirements change is an inevitable consequence.  Run from the projects that don’t have any requirements change pressures.  They don’t have a future.

Too often software managers make themselves adversaries of change.  They too frequently place the objective of hitting the release date above all other competing concerns.  The primary objective of every project is to add value — value not only as far as profitability is concerned but value in its benefits to its customers.

A successful project adds value.  I’m not suggesting that on time delivery doesn’t contribute to value.  It does, but it’s rarely as important as it’s made to be.  Take Microsoft for example.   They’ve been late on every delivery of their Windows operating system.   In spite of late shipment, they have added significant value to Microsoft and their millions of customers.   Even in my own experience, projects that were a few weeks or a few months late never had negative real consequences.  Delivering a bad release on time is always a terrible idea.

Steps for Controlling Change

The challenge for software managers is how to successfully manage change.  First, don’t view your product marketing team as an adversary.  As they are the source of a majority of your requirements change requests, it’s only natural to see them as the source of problems.   The product marketing team is working to deliver upon the customer need and thereby secure a revenue stream for the product.  Product marketing requests changes because they see an opportunity to reach more customers, to fend off a competitor, and/or at a minimum to ensure the product is received warmly. If, as the manager of the engineering effort, these aren’t your priorities, then you make it easy for your competitors to exploit your missed opportunities.

Requirement changes shouldn’t be accepted easily; they have to be controlled to meet all the project’s objectives.  Certainly as the software manager, it is your objective to ensure that all the project commitments are delivered timely, but timely doesn’t necessarily mean the original release commitment date.  Here are some strategies in priority order for managing requirements during your release.

1. Absorb the change without changing your release commitments. Many change requests are in areas that you are already working in and can be easily accommodated without impacting the schedule.  This is not debatable: just do it.
2. Offer alternative solutions to the change request that will allow you to deliver on the change and allow you to hold your release date, but don’t offer bad solutions just to maintain the date.  That benefits no one.  Take the time to understand the customer need.  In doing so, you may find there are better and easier alternatives that can be easily absorbed into the release.
3. Offer the alternative to deliver the original commitments as planned followed by a small release shortly after with the change request(s) included.  This is a great compromise approach when you know you can deliver the changes shortly after the release: something less than eight weeks has worked well for me.
4. Negotiate other features out of the release when you know the only way to deliver the change is to extend the release date.  When the delivery date is truly a priority and a small slip to the schedule is intolerable, the Product Marketing team will often work with you to change the commitments. 
5. Slip the release date.  Sometimes this is the only alternative, but this should be the last position you argue for.  If you find that you are here too frequently, something is wrong with the chemistry on your team.   As the software manager, you should feel extremely disappointed when this is the solution, but realistically sometimes it is the best solution.  Develop a feel for the difference because if you don’t your managerial skills will be doubted.
6. Don’t accept the change in the current release; look to reach agreement to move it to a future release.  Only accept change that will actually make a material difference to the success of the product.  There is no rule for this, but the good software managers know the difference and partner with their product marketing team to successfully accommodate change.

Summary

It would be easier to deliver a project as originally planned if the requirements are immutable once they are agreed upon.  However, good change is inevitable and should be embraced.  An environment that partners with change is vibrant and energetic.  Those teams are focused on the possibilities.  The word “can’t” is an anathema.  Everyone is the source of change in these environments.  These are forward looking teams, focused on the customer.  Teams that don’t partner with change are too often self-limiting and focused on what’s not possible.  They do what they’re asked to do and no more.  They are the polar opposite of all the characteristics of teams that successfully partner with change.  When you consider the alternative, partnering with change is the only sensible choice.

“Another 30 defects uncovered yesterday,” reports the QA Lead.  “Ten defects were fixed,” reports the Tech. Lead.  Taken alone these are alarming statistics, and if they persist long enough, the release date would certainly be in jeopardy.

Many software teams struggle through the QA phase with great anxiety as they normally work through the phase without a compass: nothing to tell them whether they are on track or not.  How many defects are left?  Will we be able to fix all the defects before the release date?  Will we find all the defects before the release date?  These are a few of the questions that teams have anxiety about.  It’s only until a few weeks before the planned release date that they come to grips with the realization that they are in trouble.

Measure, Graph and Track Output

Over the years, I’ve developed some tracking techniques that have helped me to control the QA phase of the software development life cycle.  I like to record, track, and graph some key statistics that I use to measure how well the project is progressing to schedule.  The data points are recorded and graphed daily in an Excel spreadsheet and maintained weekly on a historical basis.  Basically, I record the current week’s data daily in the same cell until the end of the week when the last value persists and begin the process in a new cell for the next week.

Based on the behavior of the trends, I make objective decisions for reporting status in the weekly status report.  Red means our fix rate is trending to deliver the project beyond the scheduled release date unless something is done to correct it.    Yellow means that our fix rate is trending off schedule, and if current trends persist, the project will deliver late.  Green, of course, means that the project is delivering on schedule.   I’ll detail the specific criteria for determining status later in this article.

There are 7 variables that I track during the project:

1. Actual defects found as a line plot.
2. Weekly defects found as a bar graph plot.
3. Actual defects left-to-fix as a line plot.
4. Weekly defects fixed as a bar graph plot.
5. Expected defects to find as a straight line.
6. Expected defects left-to-fix as a straight line.
7. Backlog of open defects as a line plot.

To make this all work, during the estimation phase, I estimate the total number of defects to be found and fixed before the product is released.  (I’ll discuss how I estimate these in a future article).  Figure A is an example of a typical graph with all the data points recorded.  The features of the graph as described above are labeled with their corresponding numbers.

**Note, a single click on all graphs in this article enlarges them and then reduces them after they’ve been enlarged.

Figure A. Labeled Defect Tracking Graph

Notice the 2 straight lines that cross each other.  The line starting from zero and increasing over time is the plot of the expected defects to find trend and the line starting from approximately 2000 and decreasing over time until it reaches zero is the expected defects left-to-fix trend.  The reasoning behind the behavior of the lines is that when you start the project all the defects are left-to-fix and when the project completes, there are zero defects left-to-fix. Likewise, when the project starts, none of the defects have been found, and when the project completes, all the defects have been found.

The purpose of these two lines, what I call idealized lines, is to compare and to contrast them with the corresponding actual lines for found and left-to-fix over time.  The behavior of the actual line data plots in comparison to the idealized lines gives you a measure of how well your project is progressing to schedule, and it quantifies the degree that the project is either ahead or behind schedule visually and measurably.

Calculate Project Sigma

When the fix rate is tracking ahead of schedule, the actual defects left-to-fix line plots below the expected defects left-to-fix line, and when the fix rate is tracking behind schedule the actual defects left-to-fix line plots above the expected defects left-to-fix line.  Similarly, when the find rate is tracking ahead of schedule, the actual defects found line plots above the expected defects to find line, and when the find rate is tracking behind schedule, the actual defects found line plots below the expected defects to find line. 

To get a measure of the degree the lines are behind or ahead of schedule, move the end date of the expected lines forward or backward until the actual line plots with the trend nearly identical to the expected line.  Subtract the calculated end date from the original end date. This value is what I term Project Sigma.  It is negative when the project is tracking behind schedule, and it is positive when the project is tracking ahead of schedule.  The larger the absolute value of Project Sigma, the greater your project is ahead or behind schedule. 

Calculate Project Status 

By analyzing the behavior of the actual line plots against the expected line plots it is possible to calculate and report objective and accurate project status.   As the current date approaches the release date, the actual line plots should plot with a narrow band from the expected line plots; similarly, when the project is further away from the release date, the actual line plots can plot with a wide band from the expected line plots and still deliver to schedule.  This behavior reflects the lower defect find and fix productivity early in the project and increased productivity as the project approaches the release date. Given this behavior, the thresholds for reporting status are relaxed further away from the release date and then restricted as  the release approaches the release date.

I recommend to use two thresholds to calculate project status.  The thresholds in use are determined by where the current date falls with respect to the red line date.The project red line date is the date at the point of interesection of the 2 expected lines.   When a project crosses the red line date, it is in the end game where the project team is predominantly testing the application and fixing defects.  Before the  project crosses the red line date, relax the status reporting triggers and restrict the reporting triggers when the date crosses the red line date.  Only the left-to-fix lines are used to calculate project status as the defects left-to-fix  is normally the critical path for the project: you have to find the defects before you can fix them. 

Below are suggested thresholds for calculating status.   Table 1 identifies the triggers to use for reporting status before the red line date, and Table 2 identifies the triggers to use to report status after the red line date.  First, calculate Project Sigma as described earlier.  Assuming the project has crossed the red line date,  find the column where the value of Project Sigma meets the criteria in the header.  When Project Sigma is postive, the status is naturally green, and no table lookup is required.  When Project Sigma is negative, use the absolute value of Project Sigma to index the tables.

What’s important here is the methodology — not the absolute thresholds and values.  Play with this.  You may find that you need to identify three sets of threshold criteria instead of two as I have shown.   Or, the values for indexing into the tables may not be suitable for your corporate culture, so you may decide to tighten them or relax them.  Change anything about this to suit your requirements, but change them using some logical criteria.  Don’t randomly pick a date for which you would begin using a third set of status criteria.  Create an algorithm to identify that date based on the observed behavior of your projects.

Under Estimated Project Signal

One behavior that I’ve repeatedly observed is that when the actual left-to-fix and the actual found lines intersected prior to the expected line’s intersection, it has always indicated early that the initial project estimates are wrong and the project is underestimated. This behavior is natural as most projects are optimistically estimated or, as some would argue, aggressively estimated.  If you see that behavior on your own projects, it would be a good idea to re-estimate the project.  At a minimum re-evaluate the assumptions that you based your schedule upon to confirm if they are still valid.  Chances are things have changed and you haven’t reflected that in your schedule.  This example is illustrated in Figure B.

Figure B. Actual Left-to-Fix and Actual Found Lines Cross Before Expected Lines

Calculating a New Release Date 

If while tracking your project you’ve concluded that you will not deliver on schedule, this method of tracking becomes very valuable for projecting a new release date. To project a new release date when you’ve concluded the project is off the tracks, you first re-estimate the number of defects that you expect to find and fix in the project.  Plug those new values into your Excel spreadsheet. Then extend the expected left-to-fix line until the actual left-to-fix line plots below the expected left-to-fix line.   Provided you haven’t improved your capacity to fix defects, that date is your new release date.  Figure C illustrates a project that is behind schedule, and figure D illustrates the same project with the new projected release date identified using this technique.

Figure C.  Metrics are Trending Behind Schedule

Figure D.  New Delivery Date Calculated

Summary

Using metrics based on measured output is the most reliable method for tracking a project and assessing whether the project is progressing to schedule.  Once my projects enter the test and defect fixing phase, I rely solely on the metrics and techniques described here to report status to the team and management as to how the project is progressing to schedule.   There are essentially two benefits to this approach.  One, it takes the guess work out of assessing your project status with regard to delivering on the release date. With that you can report on your project status objectively and accurately.  Two, it provides for a quantifiable methodology for controlling the productivity of your project team.  Knowing actual find and fix rates, you can add people or request overtime to bring your project in on schedule when you’ve identified a delay.  In a future article, I will describe how to use this information to motivate and focus the team to deliver on the project objectives efficiently and expeditiously.  

I know once you begin using this tool, you will find it invaluable for managing your projects.  I’ve uploaded an example spreadsheet for you to begin using on your own projects (Example Spreadsheet).  It is populated with all the data and graphs used in this article.  Give it a try, and let me know how you make out, and I’ll be happy to answer any questions you have when posted as a comment to this article. I’m sure you will find this technique invaluable as everyone has who I’ve introduced this to in the past.   Good luck!