Nike - Missing Sept 13
By: Erick Nelson
Last Updated: August 28, 2004
We are announcing that we will not be able to make the Sept 13 target date for Nike Migration. The primary reason is that interface testing and structured scenario testing were not completed in a timely manner, and we are thus too far behind to be ready on the target date.
Here are straight answers to anticipated questions.
How was the Sept 13 date set?
The original date was July 31, and the software was not complete by that time, and therefore testing had not even started. When it was clear that this date would be missed, I was asked to provide the "earliest achievable date possible": (a) achievable, because the 7/31 had clearly been too aggressive and a realistic date was desired; and (b) earliest, because of the burden of U.S. Customs work-arounds, promises to Nike, and the dependence of the Nike GPO project on this migration.
This new schedule called for 1 additional week of XML mapping (parallel with user testing); 1 week of interface map testing; 2 weeks of interface testing; then 2 weeks of system testing concurrent with Nike UAT. I also published a schedule that was to be used if it was determined that a less aggressive approach was possible - that was Oct 11.
What were the key assumptions for the schedule?
1. XML/AI mapping would be finished, in stages, by Aug 2-6. It was completed Aug 9-12, about a week late. Thus, interface testing started one week late. Explicit - part of the schedule.
2. Certain key resources would work full-time as the main testers. The lead tester became unavailable, and the worksheet testing was not done. Explicit, written and published.
3. There would be no significant contention with other migration projects. DuPont, IBM, and Rockport continued in development/testing for the duration; GPO, another Nike initiative, was added and contended for resources. General multi-tasking also made interface testing more difficult. Explicit, written and published.
4. The interface map testing was fairly straightforward and could be achieved in about a week, with the remaining time used for business rule testing and fixes. Implicit.
What slowed interface testing?
I believe there were multiple factors all contributing in various ways to excessively slow interface testing: (1) XML errors which needed correction and test re-cycling, (2) contention and multi-tasking, with occasional bottlenecks, (3) mistakes and confusion due to hurrying, fatigue, and stress, (4) lack of proper follow-up on hand-offs, (5) dependence on developers to coordinate their activities rather than over-arching coordination, (6) multiple layers with groups unused to working together (Allogis, AI, CLS/Atlas).
Where are we now?
Completed since July 31:
- We have completed all formats through AI mapping (not live interface testing) except the report files.
- The developers discovered and corrected 30 errors in their testing; another 50 problem logs uncovered in user-testing have been resolved.
- User manuals and operating procedures are under control.
- The U.S. Customs contingency plan went into place Aug 13 and is working.
- The Executive Sponsor (Bruce Grout) has been named; GCS Implementation management established (Loo Hock Eng, Lay Ping)
- The Nike Migration code base was successfully used for critical Nike GPO Aug 20 testing delivery.
- The most important and complicated format, input from Nike, was successfully translated.
Not Completed:
- Nine of the ten formats have not been successfully interface-tested relative to map accuracy and completeness.
- 10 problem logs are open
- Business-rule interface testing has not started.
- Worksheet testing (structured scenarios) is our means for knowing whether the business rules have been mapped successfully from the old system to the new. This has not been started.
- Implementation plan has not been written.
New Requirements:
- Scope creep has not been a major concern, since Nike is expecting delivery of status quo.
- However, one new requirement has surfaced in order to fit the system within DHL/DDAO operations - the ability to first enter shipment booking, followed by Allogis entry - for both Logis and Express. We will analyze to see whether this can be implemented with the turn or needs to be follow-on work.
What do we need to do in order to wrap this up?
1. Secure a day-to-day business representative, for approving UAT and making business-related decisions immediately as they arise.
2. Day by Day Plan - Process
- Timeline. Interface testing would continue uninterrupted as we work out the day to day plan.
- Plan. Propose a day by day plan for completion of project, proposing specific resources. This will specifically address solving the interface testing and worksheet testing problems, among all other tasks.
- Resources. Work with the project sponsor and others to establish specific resources by name, with allocation of hrs/week and relative priorities established between this project and other work.
- Final Plan. Meet with the responsible key developers and managers/directors, and finalize the day to day plan based upon common understanding, and commit to that in writing.
2. Day by Day Plan - Recommendations
- Secure a day-to-day business representative and the manager-level, for approving UAT and making business-related decisions immediately as they arise
- Name a an IT testing manager to personally oversee all aspects of interface testing and worksheet testing.
- Maintain strong coordination with the Nike GPO project regarding dependencies, GPO testing, and resources.