PAL (Planned Agile Leadership) Schedule

So, you bought a software package. You are satisfied that the package functionality provides a good fit for your your business and is a much better solution for the business needs than trying to write custom code. Based on your business, you figure out a good date to implement the package. This date is based on the best time for the business. If you make candy, you are not going to implement the package before Valentine’s Day or before Easter weekend.

The vendor of the package has given you an estimate of how long the package should typically take to implement for a company like yours.  At this point, you may or may not have a clear idea of what will be necessary to implement the package.  You do not know exactly what will be required. Your expectation is that the package will indeed be a good fit and minimally complicated to deploy. Of course, the package must be deployed all at one time.  You cannot deploy in bits and pieces. You might be able to do some of the data conversion early, but the main new functionality must be deployed at one point not over a period of several weeks.  

Senior management is usually excited about the package and is anxious to be able to take advantage of the new and better functionality.  They analyze the needs of the business and come up with the best time to “Go Live”.  The date is communicated to the subject matter experts and IT.  Upon a usually brief investigation, these experts come back to senior management and report that the date is impossible.  

These are the folks who know more specifically what must be done.  They are the experts and you do not ignore their input.  At this point, senior management asks, “Well, what all has to be done?” The experts are then challenged to give a clear and concise high-level summary of how the package will be implemented. Senior management is not interested in the details, they need a high-level understanding of the major project activities, how long each will take and who will do it. 

The team is faced with three challenges:

1. Come up with a reasonably based estimate on what must be done and how long it will take.
2. Establish implementation controls to provide feedback that the timeline can be met.
3. Harmonize the implementation of a software package with established agile practices.

The PAL (Planned Agile Leadership) Schedule can clearly show high level groups of efforts that everyone can understand.  Note the following illustration:

PAL Schedule

Conflict of Methodologies

In developing the schedule, the teams are faced with a challenge. You have worked hard to convert to agile processes. The deployment of a package is usually waterfall. Waterfall and agile are a little like oil and water.  They do not seem to blend well. How do you reconcile the two process models?  You want to keep your agile processes, but you have a specific deadline for the Go Live date.

Methodology reconciliation: agile vs waterfall

The implementation team is made up of subject matter experts who evaluate existing and new functionality, IT experts responsible for the infrastructure and various experts who may be necessary for specific nature of the business. These folks must meet to determine what must be done to convert to the new package software.   Lay out the big activities that must be done for each group and estimate the absolute, leanest time frame in which this can be done.  Don’t worry about the specific plans, keep it very high level.  Lay this out on a timeline which is based on the date given by senior management.  If you are new to implementing IT packages, the vendor can help to identify the high-level components which need to be considered. 

Communicate to senior management that you can make the date ONLY if the schedule can be met.  If you miss the first stage gates to proceed to the next big area, you quickly know and can demonstrate why the date is not doable.

Let’s specify what this plan is and what it is not. 

It is Not:

It is not a MS project plan. It is lean!  All tasks are not given, only the major groupings of activities. The teams should identify the tasks to complete the grouping on the schedule with a tool like Jira.  Each sprint is defined with the tasks to be completed for that sprint.  For the test team, the test period is defined with the tests to be performed and completed for that period. This should be in a tool like Jira, Jama or HP ALM.

MS Project Example

All tasks are identified in a tool.  This is agile.

Deadline

The schedule should not be a death march. It is shocking how many times a schedule is planned that is known to be impossible or at the very least, very hard on the team to accomplish.  The purpose of this schedule is to realistically estimate what, when and who should complete a deliverable for the project. It is a schedule estimate based on the team’s best reasonable guess.

It is:

A Visual Representation of the required project progress

One of the most basic elements of Agile and Six Sigma methodology is that, where possible, visual representations are good clues to the team.  This is what the PAL Schedule is…a visual representation of what must be done throughout the implementation process (beginning to end).  What makes this schedule so powerful is that it keeps a strong link between major project activities and when this must be completed to make the schedule.  Completion is linked to documented activities that are tracked in agile project tools.  In addition to tracking individual activities in the selected tool, groupings of activities are also tracked on the schedule.  The teams are color coded so that there is an immediate recognition of the elements of the schedule that the team members own.  To achieve the schedule, the teams must be ready for the next iterative and incremental phase.  Each phase is linked to criteria that must be supported by measurable and identifiable statistics generated in the tools.  If the statistics do not support the move to the next phase, senior management and the team know immediately that the schedule may be at risk.  This enables actionable knowledge much faster than is usually possible.  Remediation can take place right away to either move the schedule out or act to get back on track.

The resource creating the plan with each team should diligently work toward making the schedule easy to read and understand.  This involves putting only the need to know information on the schedule.  At various points in the project, when needed, more detailed scheduling information is published to the team.  This is given when the specific need arises. Until then, the detailed information does not need to be considered.

Task Time

Ownership: the schedule is owned by the whole team.

This is a basic tenant of agile methodology.  All team members are committed to the effort of adhering to getting their work done within the confines of the schedule. The teams are self-organizing to support and achieve the goals of the schedule.  It is good to have a formal meeting to accept the schedule. If any one team is concerned that the schedule is not realistic, these concerns should be addressed.  If the team decides to proceed with the schedule in question, it is a good idea to include the criteria that is in doubt in the readiness criteria which is specified for each major grouping.  This enables management and the team to evaluate the concern at the specific time the criteria are not met and determine remediation required.

Harness: the schedule is a harness for the Lean Agile processes.

The Agile Process is composed of sprints with specific deliverables.  These specific sprints are mapped on the schedule. It is no mystery as to what is expected to be completed during the sprint. 

Unlike the normal tracking of sprints as they occur, the schedule enables the team to keep up with what has been planned for this period from a project perspective.  This enables the team to keep up with not only the status of the sprint but the status of the project.

The Secret Sauce: The plan is based on frequent delivery of completed deliverables that are quantifiable and measurable.

The secret sauce is that the schedule is tied to frequent deliverables that are quantifiable and measurable.  All sprints, all test periods are listed.  Your sprints and test periods have specific deliverables including, at a minimum, all components of the current sprint, all tests in the period with related defects. In the clip, the periods are within the red circles.  This is the work that must be completed during this brief time period.

Note that it is specified what work will be completed.  Each detailed component is not identified on the schedule.  Rather a very high-level description of the groupings is given.  For example, for the first period listed, the team is concentrating on validating the functionality related to Customers, Jobs, Admin, Accounting, Mail and the related defects. By giving this high-level description, the entire team knows the focus area.  They are also able to identify what should and can be done and what must wait for the next iteration.  If there is some area that is not completed, this is documented so that the team knows they must swing back around to pick up this functionality and do the needful. By indicating this grouping, the team also can ensure that all areas are addressed.  These are major areas and by identifying each one, the team can schedule with a justifiable confidence that the time periods are supported.  One last benefit is that areas are not inadvertently missed. All team members can review what is listed. It is amazing that sometimes critical areas or components of critical areas are missed in the first drafts of the schedule.

These deliverables are either met or not met by the date indicated.  By tracking these deliverables, the team and senior management can know if the schedule is being met.  These statistics should be published daily. At the end of each period, statistics should be evaluated.  If the deliverables are consistently missed or critical deliverables are incomplete, the team has an early heads up that the project is not on track.

Cooperation: the team is working collaboratively.

The project can move forward only if all members work to move forward together. It is a focus for team activities and team coordination. If one team fails to meet the deliverables specified for their area, the entire project can be held back.  An example of this is the build of the test system by the IT team.  If the system is not built on time and correctly, the subsequent test periods and sprints cannot start.  If the IT structure for the integrations is not in place and operational, the related testing cannot occur. If the sprint development deliverables are incomplete, the related testing delayed.

If the data from the legacy system is not converted to be used for testing, the entire project can be delayed.  In the clip below, you can see that Core Billing Validation cannot begin without converted data.

Frequent Milestones

Frequent Milestones: milestone criteria track completion at a high level

The plan shows frequent milestones. These milestones are coordination points and exist as specific point in time on the schedule. Major milestones represent stage gates with related criteria.  If these criteria are not met, the discrepancy must be resolved and remediated. The criteria are supported by the statistics generated in the tools used.   Thus, it is measurable and verifiable that the criteria for the milestone is met. The only difference between the sprint and test period deliverables is that the milestone deliverables are at a higher level and a more comprehensive level.

Usually the milestone is the decision point upon which the team determines if the project can move forward to the next phase. The following is an example for the Milestone “Readiness for Go Live”

• All functionality is “fit” for the business.
• Outstanding defects are acceptable. They are cosmetic or there is a work-around.
• All data is converted and cleansed.
• Performance criteria have been met.
• Security/compliance requirements are met.
• Training is complete.
• Cutover plan is tested and ready.

All the above readiness criteria should be supported by demonstrable statistics. 

Communication: all needed communication should be included.

The schedule is communication rich.  Everything needed by the team to know how to move forward should be included. 

Teams are usually global and diverse.  This schedule becomes a valuable tool for all resources.  The means every team member and senior management understands and supports the schedule.

I have never worked on a project where this schedule did not become a major tool that is valued by the whole team. 

Keep it communication rich and agile lean. 

Sometimes specific communication should be published so that the team knows exactly what will happen and when. Note the starts on the clip. You see a star before the start of Integration Testing, Parallel Testing and End User Acceptance Testing. These three groupings of activities are accomplished by very widely diverse teams.  In most projects, this is truly a global effort.  IT is responsible to build the systems and the integrations; the core subject matter experts are responsible for the validation of the functionality and the End Users (who are usually new to the project) are responsible for the validation of the functionality at their site. Many of these resources need to know well in advance that this is the timing of this activity.  These end users

Team Coordination

 usually must work this validation into an already full work day.  Sometimes it is necessary for additional resources or a rescheduling because of the demands of the business conflicting with the projected schedule.  The point is, with this visual representation, the core team can make sure that the communication is broadcast far and wide so that unexpected events do not happen.

Note the clip below.  Where you see the ownership of the project activities change from one major team to another, a detailed schedule should be published to the team.  You can see the exact time and date of the transfer of ownership.  This is critical to the team and is followed religiously.  This is only sent out in a timely manner, meaning, you do not bother with this level of detail until you reach this point.  The team agrees to this before the final detailed schedule is sent.  Most of the time, this is highly negotiated.  Each team being very, very careful to ensure that they can meet this.  The resource listed is the person responsible to confirm to the team that the detailed plan is commencing. The team should also know who the team member is who has the rights to change this in process.  Because this is so critical a communication, I have rarely seen deviations once the final is published.  Usually the team is ready for this plan and deviations are too disruptive to other activities that have already been planned for this period.  So, for example, even if the activities are completed slightly early, subsequent activities are not moved in. 

Note that the detailed work to support this schedule is not provided.  This is again, a lean approach.  Do not give more information than is needed.  The work that must be done to support the schedule is detailed out by the individual teams.  Because this is so critical for so many resources, it is usually a very safe bet that the detailed work has been very carefully reviewed.  No team wants to be embarrassed that they are the ones who failed to make the schedule. In the meeting preparations for this detailed activity, the teams can explain what they intend to do to accomplish the schedule.

Ownership Transfer

How to create the PAL schedule:

The name of this schedule is PAL Schedule.  This stands for Plan Agile Leadership Schedule. In the simplest explanation of how it is done consider the activities below:

• Map the months and weeks in the header of the schedule.
• Pick a date.
• Work backwards from this date.
• Identify the major areas/teams required for the implementation. Color code the teams.
• Map major efforts on a critical path. The critical path is usually composed of the areas that are dictated by the functionality subject matter experts.
• Estimate the duration of each.
• Some areas can be done parallel, other areas require a sequential effort.
• Map the parallel efforts. This is usually the activities required for data conversion, performance, infrastructure, set up and security.
• Ensure that you note and take into consideration the dependencies.  For example, Integration testing cannot take place until the infrastructure is in place.
• Establish the milestones. The milestones are usually the end or beginning of the next major iteration.
• Identify the criteria for readiness and completeness for each milestone. This is how the team gauges what must be completed before the next sequential phase starts.  This keeps the goal clear and measurable.
• Almost all efforts are iterative and incremental.

The Lean Teams map to the PAL schedule.

• Map the sprints. 
• All sprints fit into the schedule “harness” as identified above.
• Identify the coordination points or milestones.
• All teams own the schedule and track efforts to align to the schedule.
• All team’s signoff on the schedule as “doable” if the milestone criteria are met.
• Clear, measurable data should support the readiness criteria completion.
• Metrics are published and reviewed daily.

Each team controls their own processes (sprints, project plan, task activities, testing, etc.). Team integration points are fully identified, and the timing is published to all team members.  Timing is identified by day and hour. One person owns the publication of completion of activities and transfer of task ownership.

More on “Identify Major Areas”

1. Configuration and Initial Testing (Iteration 1): The business subject matter experts (SMEs) can review the package menu structure.  The SMEs responsible for each area can review the menu structure for the area for which they are responsible.  Just by knowing the legacy functionality and seeing the number of menu options, the SMEs can give a very rough estimate for how long it would take them to configure that area and test the config.  This is the very infancy of the iterative and incremental approach.  Often at this point, only the major customer, products, etc. are addressed. The functional areas here are usually considered separately.  There is no integration of the modules considered. The data used is created by the SME.  It is not converted legacy data.
2. Data Migration Validation (Iteration 1.1): This effort is often underestimated.  This migration must be done for every major effort on the schedule.  This means that the data should be migrated for Functional Testing, System Testing, Integration Testing, End User Acceptance Testing. The time for these migrations should be considered. Some of the challenges are:
   1. One to many: one data element in legacy is converted to multiple elements.
   2. Many to one: many data elements in legacy is converted to one element.
   3. New data: data required in the new system does not exist in the legacy system.
   4. Dirty data: data in the legacy system must be cleansed before conversion.
   5. Data which is in a file in legacy is a configuration element in the new system.
3. Functional Testing (Iteration 2): This is the heavy lifting, core of the validation of the new system.  For each area, all functionality should be considered.  This is where the teams usually start with the “Happy Path”.  Start at the beginning and proceed through the functionality to the end. The IT folks usually must help here as the integration is not complete, so they may have to get data from one point to another to be able to complete the entire “Happy Path”. The SMEs usually have universal access.  SMEs are testing functionality not security. This is where the team is identifying the roles and related transactions. Completion and validation is supported by tool statistics.
4. System Integration Testing (Iteration 2.1):  The new package must integrate with the other systems.  It is important to identify all integrations on the PAL Schedule and the related testing that must take place to validate that the integration is working. It is a dreadful mistake not to identify all integrations on the schedule.  Validation is supported by the tool statistics.
5. Performance Testing (Iteration 2.2): As the SMEs proceed through Functional Testing, performance problems should be entered the test software as defects.  These defects must be addressed. The SME’s must specify what performance is required. Software tools to measure performance should be used to prove that performance criteria have been met.  These statistics are supported by the tool and are published daily.
6. System Integration Iteration 2.3): This is the work that IT must complete to be able to execute the Integration Testing.  All Integration Testing should be ‘Black Box” meaning, the IT SMEs do nothing exceptional to make the integration work.  The system should perform without any tweaking required by the IT team. This is supported by the activities identified in the tools. 
7. Security (Iteration 1-4): This is another area which is often underestimated.  Upon identifying the roles required and the transactions to attached to the role, the users are assigned a role.  This is iterative and incremental.  The key is that with each iteration grouping on the schedule, the security is nailed down more specifically and globally. You progress from the high-level definition of roles with related transactions to defining the role in the system and testing by the SME’s to End Users who are testing with their specific role. The Security team must stay ahead of the users who will be testing. This is also supported by activities required for completion entered into the tools. Statistics support completion.
8. End User Acceptance Testing (iteration 4):  End Users may be folks who are at different sites across the country or the globe for the company.  They are not the SME’s. They are the actual folks who run the company. This testing is critical. It accomplished two goals: the functionality is validated for the specific site and the End User gains invaluable knowledge about how the system works. Do not, however, confuse this with training.  Training is separate.
9. Cutover Planning and Execution (Iteration 1-4): As the teams proceed through the data migrations, they can begin to build the Cutover Plan.  By doing this, they have practiced the plan multiple times.  When ready, the IT and business SMEs can build the additional efforts required for the actual cutover.

If you have an experienced project manager, they can often draw up a first draft of the PAL Schedule with a little help.  The SME leads can then flesh out the effort and duration. The IT team is also responsible for the IT area.

Upon the completion of the first draft.  The Teams can then meet with Senior Management and discuss the schedule and agree that the date is reasonable or not.

A word of caution

The PAL Schedule is iterative and incremental.  Each phase of the schedule builds on the previous phase.  Each process area identifies tasks that are incrementally more difficult.

• Beware of the 80/20 rule. Don’t be fooled into perceiving that you have completed more work than you have actually completed. The last 20% of the functional validation is often the most complicated functionality and takes longer to accomplish that the first 80%.
• Implement the “Happy Path” as soon as possible. This means that you move from the beginning of the business process to the end in the new package.  How does it function if everything is right?  When you can progress through the functionality from beginning to end, then incrementally work in additional functionality validation.
• For very complicated functionality, write detailed, comprehensive tests prior to coding. This also required that you stabilize the data for this testing. This is a common mistake teams make.  I have heard on almost every project, “This is way too complicated to explain…” Relying on verbal explanations of how functionality should work is common.  A much better approach is to set up the test with the expected data, go through specific actions for the functionality under test and provide the expected results.  This can be done effectively on a spreadsheet. There are multiple benefits to this approach.  Many times, different subject matter experts may have different expectations on how the system should work.  The agreed upon spreadsheet takes away this misunderstanding.  If the data is not stabilized, the data can affect the expected results.  Also by creating the data or “fixing” the data element to a specific number, the subject matter experts and developers come to learn the impact of the data on the functionality.  It is very common for addition elements to be added to the stabilization routine because the team does not know to take this into consideration at the time of the test spreadsheet creation. This spreadsheet of course is in the agile supported in the tool.
• Publish tool statistics daily.  Give meaningful, actionable information in the statistics.  What is done, not done. Remember, this is where the low-level activities are linked to the Pal Schedule.  All activities should be supported in the tool. If the low-level activities in the tool are not complete, the PAL Schedule is at risk. The best statistics are often visual so include these visual clues in the statistics (burn-down charts, bar graphs, pie charts). All tools have the feature to enable the teams to drive down to the detail behind the charts. This enables the team to easily know exactly what is not done.
• Many tools have dashboards where the team can track progress. Ensure that the dashboard gives the team the information that they need to stay on track.
• Do not use email to describe or support team activities like requirements gathering, testing or defect tracking. Almost without exception, email is the bane of every implementation team.  Right at the start of the project, educate the team members on what email is acceptable and who should be copied. Team members should agree on common guidelines.  The guidelines should be consistently enforced.  Requirements should be specified in your development software (not email). Tests should be specified in the test software (not email). This software is usually very robust and gives fantastic documentation and tracking. It gives you the statistics to show the project status.  Emails can paralyze the team from top to bottom.  A word to the wise…use it sparingly.
• Test software is essential.  The metrics for the project status comes from this software.  If the requirement, activity, test, etc. is not represented in the software, IT DOES NOT COUNT. You must be able to look to the metrics to validate completion.  Sprint activities are documented. Testing is documented. When the team demonstrated that the metrics support the provable completion of the readiness criteria, management can see that the PAL Schedule can be depended upon.

A final word

In conclusion, get your folks together, come up with the plan, support all activities on the plan with demonstrable statistics, look at the statistics daily to ensure that you adhere to the plan.  What you achieve is “No surprises”.  You can clearly see that you are on schedule and will make the Go Live date.

About the Author

Leigh Koetter is a Six Sigma Master Black Belt and a Certified Project Manager with 25+ years in leadership roles for Fortune 500 global software implementations. Specialties: Program Management, Agile Processes and Methodology, Quality Management, SAP Test Management, SAP HP ALM Integration, SAP Project Management, Workday Test Management, Automated Testing