A schedule is not a plan but a plan might have a schedule in it!

A schedule is not a plan but a plan might have a schedule in it!

The first two organizations I worked for called the project schedule the ‘project plan’. A little later when I went to work for an organization that approached project management more formally, I was initially confused when a Gantt chart stopped being a project plan and my trusty plan was replaced by a document indicating how things would be approached rather than what would be done. I still occasionally conflate the concept of a project schedule with a project plan. While the two tools are related, they are different and serve different purposes.

A project plan is a deliverable used to document planning assumptions and as a vehicle to communicate the approved of scope, cost and schedule. Some form of a schedule is typically included in the plan. Inclusion of an early schedule establishes a link between the two deliverables. The Project Management Institute (PMI) indicates that the project plan is a formal, approved document. Formal project plans can include a wide array of sub-plans, including a risk management plan, quality plan or communication plan. Formal, classic project plans can be quite significant documents requiring a lot of effort to prepare. A plan and all of the sub-plans provide a platform for a project manager and stakeholders to develop a common understanding of how a project will be approached and establish roles. Many Agile projects use the Agile Team Charter to set expectations for how the project will be approached at the team level.

A cautionary note: writing and getting a plan signed-off does not ensure that all parties have developed a common understanding. Interaction and conversation are critical steps to developing a common language for the project.

Project schedules come in many forms ranging from simple approaches, such activity lists and time tables, to highly complex forms that include task network-based schedules and Critical Path Methods (CPM). A common thread in most schedules is that features, tasks and activities (or some subset) are documented and connected as a tool to guide the team and communicate progress. Agile teams use prioritized backlogs and release plans as schedules and while other methods use techniques such as milestone charts, task lists, Gantt chats and/or CPM (this only scratches the surface). Schedules act as tools to guide activities in a project, to answer the “when” questions and to help answer the “how much will this cost” questions.

Plans are a mechanism to help teams and project leaders consider how the project will be approached, to define roles and to begin to establish a common understanding between everyone involved. Project schedules reflect how the work will get done and when it will get done. Schedules reflect tactical planning, while plans take a more strategic view. Like planning, all projects use some form of scheduling technique. Team charters, backlogs, release plans, iteration backlogs, task lists or Kanban boards or project plan documents and detailed project schedules, reflect the difference in our approach and philosophy.

The schedule is not the enemy when used correctly.

The schedule is not the enemy when used correctly.

I recently asked a group of the Software Process and Measurement listeners why they hated schedules. The focus of the question was not on plans, which are documents that provide strategic direction but rather schedules which are more task oriented. The respondents were a mixture of scrum masters, project managers, process improvement leaders and change leaders primarily in software development, enhancement and support. I should note that by being readers of a process blog and/or listeners to process-related podcast the respondents marked themselves as lifelong learners and perhaps a bit outside of the norm (in a good way). However, the top five answers were:

  1. They are generally wrong. Schedules, especially anything over a longer time horizon, establish an expectation. These schedules reflect best guess and best intentions and rarely standup to what as teams wrestle with delivering value. There are all sorts of techniques to try to anticipate schedule drift, like adding padding. These techniques are tacit admissions that the schedules are generally wrong.
  2. Schedules prescribe how a problem is to be solved. A detailed schedule is the embodiment of a solution; listing the tasks that specify what is to be done and when it needs to start and be completed. However, as most projects progress, the solution as it was originally conceived, evolves. This renders a detailed schedule moot.
  3. Schedules are someone else’s idea of what should happen. Project managers or tech/test leaders are often tasked with creating schedules (this even happens on Agile teams when someone else breaks tasks down and assigns the work). Schedules are created with input or buy-in from the team doing the work yielding animosity and stress from the team. Release and iteration planning are Agile’s solutions to these problems.
  4. Schedules reduce team behavior. One attribute of an Agile team is supportive behavior. Teams commit to work and then, when needed, swarm to tasks and features so that the team can meet its commitment. Detailed project schedule commits team members to performing specific tasks in a specific order.  The schedule gets in the way of team members being able to use self-organizing techniques like swarming.
  5. Detailed schedules take a huge amount of upkeep. One respondent suggested that for any project scheduled to take more than a year to complete, one person should be allocated to maintaining the schedule. That included chasing team members for updates, resolving conflicts and in general being a pain. Other respondents were less specific, but indicated that the cost of the schedule was more than the value.

The question generated responses that were oriented detailed project schedules typically found in projects managed using classic project management techniques.  A few respondents pointed out the value of detailed project schedules. Some of the benefits included the ability to distribute and direct work across distributed teams and to facilitate a discussion of when the project would deliver. It should be noted that these responses came from more command and control oriented organizations. Respondents with a background in Agile tended to point out that while they did not feel that a classic project schedule made sense, the combination of product backlog and sprint level task list was a necessity.


A map is a plan.

A map is a plan.

All projects should have some sort of plan. Whether that plan is a classic project plan and schedule or a prioritized backlog and a release plan. A plan helps answer stakeholder questions and, perhaps more importantly, it reflects the philosophy of the project. In order for a plan of any type to be helpful, the plan and philosophy must be possible. Bob Ferguson (Listen to SPaMCAST 240) said that there were ways to detect a plan what was not possible. Several of the rules of thumb that Bob suggested (augmented with a few of my own) are:

  1. Difficult work is done late. This is on both of our lists. Teams that avoid addressing difficult or technically complex stories backload risk, which can impact a project’s ability to deliver value. Conceptually this problem should be harder in Agile, assuming stories or features are prioritized in value order and the inter-relationship between features is factored into the value discussion.
  2. Learning is not explicitly planned. Any project that is creating new features or a new product should have prototyping built into the process used to gather requirements and build a backlog. Experiments/prototypes also can and should be used to prove solutions that are complex or cutting edge (at least for the team). This item was on Bob’s list and not on mine; it is now.
  3. Rate of story completion is not feasible. If the plan can’t be completed given the team’s (or teams’) level of velocity or productivity, then it is a bad plan. Plans that specify the amounts of functionality to be delivered, the date of delivery and the budget to be spent have credibility problems, however when they are developed using wishful thinking productivity rates they enter into the impossible range. This one is on my list and not Bob’s (in your face Bob).
  4. Belief that the plan — is THE Plan. A plan, schedule or backlog that does not change for a project of any moderate or large size is wrong or if it actually works is  the reflection of sheer dumb luck (Harry Potter reference – reread Harry Potter and the Philosopher’s Stone.). Anyone that falls into the trap of absolute belief that any project deliverable can be created once and referenced forever will find delivering value difficult at best.
  5. Not involving the business. The real product owner(s) must be part of the product to act as an active conduit of business acumen into the team to minimize wait and search time. All too often business stakeholders have been taught treat the boundary between IT and the business as a demilitarized zone where information hand-offs occur on a periodic basis. This behavior makes planning and maintaining any sort of plan difficult at best which slows the project down. IT teams often elect proxy product owners from inside the IT boundary leading to the same result (I heard this termed all of the responsibility and none of the authority). Proxy product owners can’t provide the level of feedback on priorities and the plan that the business can.

Plans have value only if they are current and only if maintaining plans, schedules, backlogs and the release plans do not become the goal of the project. Planning helps teams to develop a strategy for delivering value, but they must be allowed to change. Change is inevitable because we are learning both personally and about our project everyday. Not using what we learn is silly!




Listen to SPaMCAST 300

Show 300! Show Zero was published on January 7, 2007. 2,738 days later, we feature our interview with Vasco Duarte. We discussed #NoEstimates, which evokes a great deal of passion.  The interview will embraces that passion and we sort through the noise to get to the core of the idea which is highly useful despite all of the controversy. #NoEstimates asks teams, product owners and leaders to rethink how they predict project performance.  Change is hard but Vasco describes a less painful path to predicting delivery.

Vasco’s Bio:

Product manager, scrum master, project manager, director, and Agile coach are only some of the roles that Vasco has taken in software development organizations. That experience has been gained by having worked in the software industry since 1997, and being an Agile practitioner since 2004. Vasco has worked in small, medium and large software organizations as an Agile Coach or leader in Agile adoption. He was one of the leaders and catalysts of Agile methods and Agile culture adoption at Avira, Nokia and F-Secure.

Vasco’s blog can be found at http://SoftwareDevelopmentToday.com

Follow Vasco on Twitter @duarte_vasco


Software Process and Measurement Cast number 301 will feature our essay on technical debt. Technical debt is the work not done or the shortcuts taken when delivering a product. We all take shortcuts, but at what cost?

Upcoming Events

I will be attending Agile 2014 in Orlando, July 28 through August 1, 2014.  It would be great to get together with SPaMCAST listeners, let me know if you are attending.

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested!

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.




Putting the parts together!

Putting the parts together!

Hand Drawn Chart Saturday

Techniques for building an initial backlog can be classified by how the conversation between stakeholders and the project team is initiated. Some techniques are focused on asking, other techniques focus on observing, while the third category is all about showing something and getting reactions. Most practitioners blend the best from each of the categories. Here are some examples of the hybrid techniques:

Role Playing Prototype: This technique blends paper prototypes (show) with role-playing (observe) to get users and stakeholders to consider how they might act in an environment that has not been fully designed.

Straw man/JAD: This synthesis seeds a JAD session (ask) with an loose outline of a solution or set of potential solutions that are used to guide the discussion which are at the core of JAD. However, the seeding tactic can inhibit creativity. The technique is less constraining when a set of competing solutions is used as the conversation seed, however developing the range of solutions before the JAD session  increases the cost of the JAD.

Embedding: This techniques puts team member(s) into a department to actually perform the work (observe) alongside actual users and stakeholders. This generally requires the embedded team member to be trained and mentored to intimately see how the work is done. I have seen debrief sessions added to this technique to ensure that participants get a chance to discuss the nuances in the workflow.   As I have noted before, with any observation technique everyone needs to understand what is going on and why. This is not an episode of Undercover Boss.

Combining tactics from different categories of techniques that teams use to develop an initial backlog can fundamentally change the dynamics of the requirements definition session. A group of stakeholders will generally have a diverse range of learning and interaction styles that they favor. Combining backlog building techniques gives the project team a better chance at making a connection. Combining techniques should not be done randomly or an ad-hoc basis. Selecting which techniques to combine has four prerequisites:

  1. Someone with experience and training (perhaps a business analyst).
  2. A knowledge of the user community (knowledge the product owner can provide).
  3. Planning (time and effort).
  4. Involved users and stakeholders (call on the product owner and project sponsor to help with this prerequisite).

Developing an initial backlog is a step to get projects going and moving in the right direction. It is, however, only a first step. Backlogs will evolve. Teams, product owners, users and other stakeholders will gain knowledge and experience as the project move forward that will continually shape and reshape the backlog.

The evacuation instructions could be a form of paper prototype.

The evacuation instructions could be a form of paper prototype.

The most powerful single technique for generating requirements is showing users and stakeholders something and collecting reactions. There are numerous techniques for developing something to generate feedback, ranging from functional code that could implemented in production at one extreme, to functional prototypes in the middle, to paper prototypes at the end of the scale. Functional code is used to generate feedback to evolve the backlog in Agile projects, however showing techniques are not used as often as they should be to generate the initial requirements backlog. The reason these techniques are not used is the perceived level of effort needed to generate the prototypes or an impetus to begin building the solution immediately.

The power of the showing techniques is based on the theory that many people only know what they want when they see it. The process of generating feedback and requirements is also risk management. A prototype reduces the risk that the project will either build the wrong thing or build the right thing wrong. Functional prototypes also, to an extent, are useful to prove that a solution is at least conceptually feasible (prototypes are generally too small and not fully functional therefore do not truly serve to prove technical feasibility). Paper prototypes address generating requirements and reducing risk but are faster and cheaper to generate because there is no code or code related infrastructure. A very simple example of a paper prototype for a customer relationship management system (CRM) might be set of drawings of screens to show the rough flow of work.  Users to use the paper screens to imagine the process and discuss the flow. In comparison a functional prototype would have mock screen on a computer show system flow but typically without any background functionality.

The first issue with prototypes is that developing them requires time and effort. Project teams are often presented with a goal, a budget and a deadline. In most corporate IT organizations, performance against the project budget is considered a critical measure of progress (and in the longer term, project success). Therefore teams and project/program managers mercilessly manage the budget to improve the possibility of project success. Unless prototyping is built into the budget and the planned approach for the project, there will be pressure to use the less costly, albeit less effective, asking techniques to generate requirements. Teams, sponsors and project managers make a rational choice to manage the budget risk against the possibility of not generating a good enough backlog to get started. However, generating requirements using prototypes is a process that can used to balance requirements and budget risk. The higher the risk of not having a more through early backlog the more important techniques like prototyping will become to mitigate that risk.

The second issue that the use of prototypes face is what I call “starting fever.” In many methods, including Agile, the whole cross-functional project team is assembled to start the project. There are many individuals that don’t believe that gathering requirement is important, therefore unless there is something for them to build or test, they will find other things to do. There are numerous ways to deal with this type of structural slack; here are two extreme cases will illustrate the range. The first solution is to have a subset of the team (like the Three Amigos) generate the initial backlog before kicking the project off. The second solution is have the whole team spend a day as the project kicks off to generate a quick initial backlog and then use the demonstrations at the end of each sprint to continue to flesh out the backlog. I lean towards scenario one or variants in which the other portions of the team work on framing the technical and physical infrastructure.

Another way “starting fever” can be triggered is because of the panic a fixed budget, fixed scope and fixed date project that someone actually said yes to before requirements are known can cause. Before you protest, regardless of how much every developer, tester, BA, project manager or CIO believes in that this an irrational situation they happen ( I see this as the norm in some organizations) and they casue teams to abandon good  practices like prototyping. In the long run project teams have to pick up the pieces when these types of projects had problems. When teams are put under immediate schedule, budget and scope pressure, leaping into action and then creating and firming up a backlog later can look like a great solution. Action is still equated to progress.

Prototyping is an effective tool for driving out requirements that can’t be expressed until they are seen. The backlog building techniques that show the users and stakeholders something to react to also serves to mitigate the risk of building the wrong thing or the right thing wrong. The power of these techniques is offset by the cost and time required to generate prototypes and a fear that unless you are building something the project has started and the due date is at risk.


One of my jobs during high school was in a tire manufacturing plant in Memphis, Tennessee. On more than one occasion the hated and dreaded time and motion “guy” showed up to observe how I was doing my job. I never knew what the outcome of the observation was or whether the change to the four page process I performed to sort green tires was due to the observation. The job was never easier after the change. Reflecting on that time (and several industrial classes later) I understand that observation is an important tool for developing an understanding of how work should be done, but is not a tool to be used all the time. Using observation in the right scenarios and then taking steps to plan how you will observe is critical getting value for the effort needed.

Why observe? The simplest and clearest rational for using observation techniques is that users and stakeholders either don’t always know what they want or can’t always express their current needs and foresee their future needs. Therefore a new set of eyes will expose more and different needs. There are four typical reasons for observing should be considered as a tool gather knowledge and requirements.

  1. Physical location is a determinant. Processes and work flow is often affected by the physical location. When the physical layout of the people or machines could strongly affect the solution the team developing the initial backlog should observe the process in action to understand the nuances of flow of work.
  2. When people can’t tell you. Occasionally the process being studied will be so complex that no one is able to coherently describe how it works or how it should work. Even more occasionally asking is met by silence due to lack of trust. In both cases observation is a valid tool to develop an initial backlog.
  3. When interactions are crucial. Complex processes often require a wide range of interactions between people, tool and applications. Interactions, except when they cross the boundary, are difficult to identify unless you see them.
  4. When the output and the process don’t match. When, on occasion, the measured output or the output described by a manager does no match what is possible based on the published process then observing the real process is mandatory.

Once you have decided that you must observe, planning becomes a necessity.

  1. Begin by reviewing the known policies, culture and process of the organization or team being observed. This step helps to ensure that you have a sense of the environment and what you will be seeing.
  2. Decide on how long you will observe. Some processes and process variations need time to be seen. If a process requires a week to complete you will need to observe for at least that amount of time.
  3. Determine how you will record what you see. Trying memorize what you see will result in some information, however you will at least need to take notes. Remember that recording can include taking notes or recording audio and video. The level of detail needed will help determine the method needed.
  4. Finalize the logistics of the observation session before showing up. Office space, network and physical access can suck up huge quantities of time and effort. If you have a week for observation do not spend the first day dealing with administration tasks.
  5. Decide how you will create rapport with the group you are observing. Your presence will cause disruption. You need to find a way of observing with minimal impact to the results and without scaring those you are observing into calling placement firms. I am a fan of transparency; tell people why you observing and what will be done with the data. Where possible I usually involve those that I have observed in an early review of the data collected to elicit more information (hybridization of techniques by combining observing and asking).
  6. Finally do what was planned, but do not be afraid to tweak the plan as needed.

When I was in the tire plant, the time and motion guy would just appear and no one was thrilled. When we saw him coming we followed the proscribed process a bit more carefully, even if it was less effective. Observation can change behavior positively or negatively (Hawthorne effect). Sometimes observation might be the only way to know what is really happening, but without planning the data you gather might be what someone wants you to know rather than what you need to know.


Get every new post delivered to your Inbox.

Join 3,591 other followers