Analyzing Scope Creep

I don't think I've been involved in a project that didn't have scope creep. There is a reason it's called creep - often it is insidious, introduced by a "could you just tweak this" and followed by a  "it doesn't look like quite right  - could you just change that a tiny bit".  Then comes the "Oh, ah, I forgot about that.  Can we change that?  It's really important."  Pretty soon you'll be adding a whole new module (or two) to whatever project you are working on.

I will share a recent project that demonstrates significant scope creep. This was an internal project within my district. There were only a couple of people involved in the project, one was the subject matter expert (SME) and the other was the Project Manager/Developer. The goal was to create a relatively simple program that would help capture and summarize information from a district-wide student writing assessment.   Teachers would enter student scores on a worksheet. These worksheets would then be collected in a common electronic folder.  Using some simple programming, the teacher worksheets would be summarized by school and grade.   With a little more programming, the school summaries would be combined to create a district summary by grade.  Just a small, simple project to help evaluate our students' writing abilities.

The first step was for the Project Manager/Developer to understand exactly what was needed.  The SME indicated that writing results would be captured for students in grades 1 to 4 and grades 6 and 7.  Grades 5 and 8 were not included because these grades took a writing test as part of the statewide assessment.  An informal project plan was created, allotting time for design, programming/development, testing, and finally delivery to the schools. Everything could be done within four weeks.  

The next step was to determine exactly how we would capture the writing results and create school and district summaries for each grade. The Project Manager/Developer sketched out a worksheet that would capture the information.  The SME explained that some teachers would have one class, others would have two classes, and middle school teachers would typically have four classes.  We decided that we would create a workbook with four individual worksheets, each of which would be used to document the scores of one class.  An additional worksheet would provide the summary of all the teacher's classes.  This additional worksheet required no manual intervention, it simply used formulas and simple logic to determine how many worksheets were completed and what information needed to be summarized. 

We then designed a worksheet that summarized each teachers results by school and grade.  The summarization would be done with programming and no need for manual copy and paste.  Finally, we designed a worksheet would summarize each school's results, providing district-wide results by grade.  Again the summarization would be automated using programming.

Once the SME had reviewed and approved the worksheets and how the summarization would be done, the programmer implemented the worksheets and the code required to automate the summarization.   The project was now about three-fourths done, and that's when the scope started creeping.

As the programmer was putting the final touches on the coding, the SME stopped by.  She started with an apology – never a good thing.  She had neglected to tell the Programmer/Project Manager that the rubric used for grades 3, 4, 6, and 7 was different than the rubric for grades one and two.  That was the first "oops". 

The Programmer/Project Manager revised the project plan, adding a week to allow the revision to support this additional functionality.  Then the SME remembered that the first grade rubric was actually a little different that the second grade rubric.  The project scope creeps further.

The plan is adjusted (again), and the changes are made.  The workbooks are disseminated to the schools.  That's when we discover that different schools have different versions of the spreadsheet application, and that is causing problems in the data entry and automated summarization.  Now the project is creeping like a long shadow in a scary movie. 

Ultimately, we were able to revise the application and successfully summarize all the data.  Unfortunately, the project took almost twice as long as expected.  Fortunately, we were all in the same organization and worked very well together to address the challenges presented.  If the programming had been outsourced, we likely would have ended up in mediation or even a lawsuit.  At the least, there would have a very unhappy client and a frustrated provider who probably spent more on the project than what they were paid.

So how do you avoid scope creep?  One of the primary issues on this project was the failure to accurately and completely identified the requirements.  Lynch and Roecker (2007)  point out that changes can occur due to requirements that "are not properly defined, documented, and controlled"  (p. 96).  That certainly applies to this project.  Perhaps if the Project Manager had spent more time  reviewing the requirements and asking probing questions, the differences in the rubrics for certain grade levels would have been uncovered.  Similarly, if the SME had thought longer and more deeply about the process that was being automated, she may have identified the oversight of documenting the differences in the rubrics.  Generally, when a project goes awry, there is plenty of could have, would have, and should have for all members of the project team.

Perhaps more frequent status updates and reviews would have uncovered the oversights in the design earlier in the process.  As Portny et. al. (2008) point out, reporting provides an "opportunity to see whether a project is on track and to determine whether they should do something differently" (p.324).  One important thing in our favor was the strength of the project team.  Greer (2010)  speaks to the importance of including all stakeholders in the project and building relationships.  He also points out that when project scope issues arise,  deal with it calmly.  Project scope changes are normal, and a project manager needs to deal with it in a matter-of-fact fashion.  Focus on moving forward, and document the changes in the event you have to later explain the cause of the scope changes and the decisions that were made to address those changes.

References

Greer, M. (2010).  The project management minimalist: Just enough PM to rock your projects! (Laureate custom ed.). Baltimore: Laureate Education, Inc.

Lynch, M., & Roecker, J. (2007). Project managing e-learning: A handbook for successful design, delivery, and management. London: Routhledge.  Copyright by Taylor & Francis Group, LLC.

Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Project management: Planning, scheduling, and controlling projects. Hoboken, NJ: John Wiley & Sons, Inc

Communicating Effectively
 

What an interesting exercise!  I don't think I ever really stopped to consider how the same message can be received so differently just based on the medium in which it is delivered.  When delivering project related communication, I have a strong tendency to communicate in e-mail or other written form. This tendency has a lot to do with the fact that the written communication serves to document questions, responses, activities, and decisions.  The second most common way that I communicate project -related information is in meetings.  In addition to verbal discussion, written information is employed to preview key agenda topics, summarize the meeting, and document outcomes.  Again the written word provides confirmation of decisions made and items discussed.

In the exercise, the exact same message was delivered in multiple ways. In the e-mail delivery, it was clear that Jane needed a report from Mark to finish her own work. While she stated that she understood that Mark was busy, she also made it clear that the information she needed was affecting her ability to complete her assignment.  The tone was pleasant and the need was clear.  Unfortunately, for many busy individuals, it is easy to ignore an e-mail or to forget their intention to address an e-mail.  Another issue with e-mail is that you may not know if or when your recipient opened and read the message, unless your messaging systems provides this capability.  Further, with the ever present smart device, the intended recipient may receive the message during non-working hours, making it easy to forget to respond to the e-mail the next morning.

The message was then delivered through voicemail.  The words were the same and the need was the same, but the voice conveyed more urgency that I felt was conveyed in the written message. The tone of the voice and the insistence in that voice made it harder to ignore the message.  To me, it somehow made the request more important than when the same message was delivered via e-mail.  However there are also issues with voicemail.  Like e-mail, you don't really know when the recipient actually listens to the voicemail.  Like e-mail, mobile devices mean that the message may be delivered off-hours, in meetings, or at other times when it is inconvenient to respond. So like e-mail, the individual may forget to respond to the need.

Finally the message was delivered verbally and  face-to-face.  Without doubt, this is the best way to actually achieve the goal, which is getting the report or the data needed.  Because the request was delivered in person, Mark is more likely to respond quickly to the request. It is much harder to forget or delay the delivery of the information that Jane needs. The face-to-face seems to make the request more personal.  In addition to words, the body language impacts how the request is received. In the video, Jane clearly indicated that urgency but also recognized that Mark was busy.  Her demeanor suggests she hates to ask, but must do so.  Her tone and demeanor conveyed sympathy and consideration. In my view, the face-to-face delivery of the message was far more likely to yield the desired results, that being the report or the data.

This is an important lesson in effective communication. While e-mail or voicemail may be more convenient and require less personal effort, it may not result in the most timely response.  Portny, Mantel, Meredith, Shafer, Sutton and Kramer (2008) speak to the importance of choosing the appropriate communication for the task.  Communication not only includes exchanging information, but it also influences "one another's attitudes, behaviors, and understandings" (p. 357).  Stolovich (n.d.) also comments on the importance of face-to-face communication, noting that as much as 93% of communication has nothing to do with words.  Attitude, body language, timing and personality are major  factors in effective communication.  This speaks to the importance of periodic face-to-face meetings. While technology makes it easier for people to communicate without being in the same space, it is still important for relationship building to include face-to-face communication among project team members and stakeholders.  That face-to-face communication can then be followed up with written confirmation to document deliverables or actions requested.

References

Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Project management: Planning, scheduling, and controlling projects. Hoboken, NJ: John Wiley & Sons, Inc

Stolovitch, H. (n.d.).  Project Management and Instructional Design  [video].  Retrieved from http://sylvan.live.ecollege.com/ec/crs/default.learn?CourseID=6051999&Survey=1&47=5871191&ClientNodeID=984650&coursenav=1&bhcp=1

Project Post Mortem

In this week's installment, we are evaluating past projects to determine the good and the bad. Just as reflection supports deeper learning, reflection of a project helps us learn how to become better project managers.  I considered several past projects for this assignment, and it was a difficult choice. Each project brings its own learning opportunities. I finally settled on a recent project in which 3000 iPads were distributed to high school students.  As you might think that simply handing out computers would be rather easy, but it's not. In order to put 3000 iPads in the hands of 3000 students was a ballet of paperwork, people, and technology.

This project had two primary phases. The first phase was an mandatory orientation for students and their parents and guardians.  Parents and students were asked to come to the school on specific days during specific times in order to attend a presentation about how the iPads would be used and then complete documentation allowing their student to receive an iPad.  Student and parent entered the school building, picked up their paperwork packet, and were shepherded to an auditorium where they were given a 15 minute presentation about the iPads.  After the presentation, they moved to the cafeteria where they filled in paperwork, submitted forms at two different stations, and paid for insurance on the iPad. On four different nights, three different sessions were held.  In each session, 200 to 300 students and their parents attended.  Each session was scheduled for an hour, but in most cases all students and parents were in and out within 30 to 40 minutes.

The second phase was the distribution and initialization of the iPads. During the first period of each day during a five-day period, approximately 600 students were shuffled to the cafeteria, ”little" theater, "large" theater, and media center where they received their iPad and completed an initialization process for that device.  This challenging project the required tremendous coordination and planning.

Overall this project was a success, though not without a few challenges.  TOne of the things that was done incredibly well was the coordination of a large number of individuals to support the processes.  Another thing that was done incredibly well was the preparation for the orientation and for the iPad distribution.  The specifications for the flow of people in both the orientation and the distribution was detailed and designed for efficiency.  Additional manpower to help direct and support the processes  were clearly instructed on how they needed to complete their specific assignment.   Assignments during orientation included

·         handing out packets after verifying the identity of each students parent or guardian,

·         directing students and their parents to the presentation location,

·         using both live and prerecorded to ensure every group the same message in information,

·         moving the group to the cafeteria where they could complete and return the required paperwork, and

·         the process for submitting forms and paying fees.

Likewise the coordination process was carefully planned and executed. Students were brought to the cafeteria in class groups, signed for and received their iPad ,  and then followed a step-by-step presentation on the steps required to initialize their iPad.  Instructional technology specialists,

 and information technology technicians, teachers, and school and district administrators monitored the initialization process and provided one-on-one support as needed.  I would say that this project team was particularly effective in completing the steps in Greer's (2010) second and third phase, which covered creating clear and detailed specifications  and communicating these to other stakeholders. The specifications of key processes, and the communication of these specifications to other stakeholoders resulted in a very efficient completion of the distribution.

The primary issues encountered were related to technical problems.  On the first day of iPad distribution, students were unable to complete the required initialization process because of an update to the software being used for the initialization.  In technology, it is important to test any changes in order to prevent these kinds of issues.  There was nothing in the project plan that addressed updates were testing of those of dates.  Another shortcoming was the fact that the step-by-step presentation given to the students was apparently not tested prior to the actual use by students.  This resulted in minor problems and unexpected revisions of the presentation and associated guide during the distribution process.  Again, this relates to a lack of change testing activities in the project plan.

So in summary, the detailed specifications and communications were instrumental in the positive results.   The action and people processes were clearly identified and tested, while the technology processes did not include key steps for testing those processes.

References

Greer, M. (2010). The project management minimalist: Just enough PM to rock your projects! (Laureate custom ed.). Baltimore: Laureate Education, Inc.

Greetings, followers!

I look forward to learning about Project Management with all of you!