From: Susan Parker
Sent: Monday, May 20, 2013 12:34 PM
To: John Piette; Jim Maloy; Owen Richardson; Steven Borowick
Subject: getting a handle on a moving target
Importance: High
As you know, I’ve been going through wiki documentation to try to ensure that the status of specifications is clear, and to clean up outdated or duplicative material that is potentially confusing.
One of the steps I’ve taken is to modify the title of each main specifications page to indicate status – final, in progress, on hold, not started. Since “FINAL” may be misleading, I’ve changed it to COMPLETE.
1. Regardless of what we call it, here is what this status means to me:
- The design team considers it as complete as it can be. The design team is no longer tinkering with it, it has Ladd's and Dawn's approval, and is ready for developers to review and begin work. The only substantive changes under consideration after a design is deemed “complete” are those which address problems or issues that were not foreseen at the time it was deemed complete.
- For example, during the process of designing checkout screens, we determine that within the shop widget, our handling of customer pick up intention is inadequate. Or, programming brings to our attention that the level of effort required is so extensive for a particular feature, it may warrant a different approach.
- If, on the other hand, programmers or anyone else brings to our attention major gaps in the specifications, i.e., specifications that we perhaps could have or should have foreseen needing to be documented or designed, I will revert the title of the page to “ … IN PROGRESS” and we will make updates to the main specifications page. (This is what I have done with Saved Items, because of a few gaps with functionality that John brought to our attention; Steve and I are working to address.)
- Loose ends and minor details will be addressed as edits to the main specs page as well, without a change of status from “COMPLETE” to “IN PROGRESS”
2. “Changes”
If we find ourselves actually making changes – i.e. finding we have to reverse ourselves on some key aspect of design or functionality due to unforeseen issues, I will log changes on a separate changes page (a child page under the main specs’ page). This is so that we do not have to go back and re-dot i’s or re-cross t’s in the original specifications (i.e. fixing every mention of “editable UOM” to now say “non-editable”, or introduce all sorts of confusing caveats (i.e., “this image is no longer accurate with respect to X, Y or Z…”). This could be a huge effort, and still may not produce clearer, more accurate or complete reference for programmers.
There are two types of changes – those deemed critical for launch (essentially, something will be broken if we don’t make the change) and post-freeze (post-launch) changes.
To make it easier for programmers to see all of the pre-launch changes in one place, I’ve created a page in Confluence that will automatically suck these changes in: Design change summary.
Please note – this system is not foolproof; there are going to be times when changes fall into a gray area -- i.e. was the original spec’ incomplete, or are we changing the existing spec. or none of the above? I don’t have an answer to that, other than to be in close communication, generally speaking, as we should be anyway. And as always, I am open to suggested improvements.
_________________________________________________________________________________________
Susan Parker | Senior Project Manager | LADDAWN, 155 Jackson Road, Devens, MA 01434-5614
(: 978.563.6148 | 800.446.3639, x6148 | Ê: 978.772.7792 | www.laddawn.com | Twitter @Laddawn