Just One More Thing...

I vividly remember a major project in the late 1990’s in which our time and attendance software needed to update all existing software to handle the year 2000 and beyond. The legacy software which lots of clients still used had algorithms built into the code which invalidated the year “00” and the century “20”. As you can predicate, “Project 2K” initially had a narrow scope, make sure all time and attendance reports and date references could handle the year 2000.  This project was critical since small companies used the software to prepare payroll and the thought of our software blowing up on the eve of the year 2000 was unconscionable.

Scope creep reared its ugly head, as the marketing team began making requests to add in some new reports with this same release.   Dr. Stolovich states in Project Mangement Concerns,

 

      "Let the client know that their additional ideas and wants are very valuable, but let's finish the 
      project that's been spec'd and revise that once its tested and acceptable to add additional
      features or to meet another need." (Stolovich, n.d.)

In this scenario, the director of engineering who managed all of the software projects, diplomatically valued the request for the new reports and assured the stakeholders that would be added in the next release.  After several passionate meetings, an informal change control system, the C.E.O. of the company determined that at least two reports would be added to this release within the same timeframe.  Dr. Stolovitch recommends using a change of scope document in Monitoring Projects to get written confirmation and clarification of the change to the original scope of the project. It clearly lays out what the change is, what the implications are, what the timeline, resources, budget, and deliverables are going to be and going to be effected. You work the change of scope document with the client and get their commitment and signoff and then you communicate the changes, and you reallocate time and resources. (Stolovich, n.d.)

Scope creep always has residual effects.  In this case, additional quality assurance personnel had to be added to the project. Some were dedicated to testing the upgrade of all releases of the software on various platforms.  The additional Q&A resources were used to test the new reports.  Although the timeframe was met, the number of hours expended by human capital and additional resources dedicated to the project halted all other projects until this release was completed. 
 
Profit is always a game changer.  Reflecting on this project now, if I were the project manager back then, I would have done a cost variance and estimate at completion.   If the C.E.O. were provided with the actual costs of adding these reports to the current release and the difference between what the original scope of the project and the cost of letting another project be shelved to reallocate the Q&A personnel to this project, it might have vetoed the reports in this release.  The Earned Value Analysis helps project managers determine whether a project is ahead or behind schedule and whether it’s over or under budget, while only tracking resource expenditures. (Portny, Mantel, Meredith, Shafer, Sutton, and Kramer, 2008, p.327).
 

References:

            Dilbert Comic retrieved by http://cloud-juice.net/wp-content/uploads/2012/01/dilbert_creep.png

           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.

            Stolovich, H. (Producer). (n.d.) Monitoring Projects. Laureate Education, Inc. Retrieved from https://class.waldenu.edu/webapps/portal/frameset.jsp?tab_tab_group_id=_2_1&url=%2Fwebapps%2Fblackboard%2Fexecute%2Flauncher%3Fype%3DCourse%26id%3D_2823017_1%26url%3D

 

Stolovich, H. (Producer). (n.d.)Project Management Concerns: ‘Scope Creep’. Laureate Education, Inc. Retrieved from https://class.waldenu.edu/webapps/portal/frameset.jsp?tab_tab_group_id=_2_1&url=%2Fwebapps%2Fblackboard%2Fexecute%2Flauncher%3Ftype%3DCourse%26id%3D_1373695_1%26url%3D

 

The Art of Effective Communication

The multimedia program, "The Art of Effective Communication." views a piece of communication in three different modalities: as written text, as audio, and as video.

EMAIL

Jan selected appropriate words and phrases in her email message to Mark. She expressed empathy in the first sentence by recognizing that she knows that is busy and might have had to attend the all day meeting (giving him the benefit of the doubt). She clearly communicated the information needed (his report) and why. Portny, Mantel, Meredith, Shafer, Sutton, and Kramer, say to “Clearly describe any actions that people should take based on the information in the report. “ (Portney et. al., 2008). Jan asks for Mark’s report yet offers an option to send her the data in place of the full report in order to meet her own deadlines.

VOICEMAIL

The voicemail expressing the exact same information was more personal. She kept the same tone through most of the message and did not modulate until she said, “I really appreciate your help.” This was effective as she is appealing to him for assistance.

FACE TO FACE

The face to face conversation eliminates misunderstandings that written communications can infer. Face to Face communication allows for an immediate response, and provides a setting for dialogue exchange. Jan begins the conversation with a smile, although her facial expressions become more serious yet non-threatening as she expresses the need for the data. I think this form of communication is always best. You are able to read the body language, watch the facial expressions, and have the opportunity to ask questions and clarify what you understood the other person to say.

Reference

Laureate Education, Inc. (n.d.) The Art of Effective Communication. [Video Webcast]. Retrieved from http://mym.cdn.laureate-media.com/2dett4d/Walden/EDUC/6145/03/mm/aoc/index.html

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.

Learning from a Project “Post-mortem”

Years ago in what seems like another life, I worked as a software engineer on an engineering team for a small family-owned corporation.  There was no official PM, so the Director of Engineering assumed that role.  The core business was manufacturing time clocks, although the time and attendance software which was developed for a specific line of clocks was a rapidly growing part of the company.  The executive team, (C.E.O., director of marketing, director of engineering, vice president of manufacturing, and purchasing agent) would work together on the high-level requirements of the project.  The director of engineering would then bring the requirements to our team to gather information, ask additional questions, mock up a user interface for the software and give initial feedback to the marketing team.  The screen shots provided would either be approved or tweaked based on their understanding of the user’s requests.  The project would progress through the software development life cycle before a new release was actually burned to CDs.

The company I worked for did not have a “formal post-mortem” process.  By that I mean there was no report, no comprehensive notes taken along the way to review at the end, or team reflection. Instead, we discussed loosely what gotchas came up during testing such as the release of a new operating system which in those days was either 16-bit or 32-bit platforms, third party dynamic link libraries which were incompatible with a specific operating system, etc.  So were we proud of the finished deliverables?  In all cases we were, because end-users were often able to beta test the software before the full release.

Scope creep was the most frustrating part of our project.  In a small company, the inevitable, “just one more feature” was guaranteed.  Unfortunately, that feature would be larger than the scope of the original project and would add on weeks if not months to the release date of the software.   Dr. Stolovich says, "Let the client know that their additional ideas and wants are very valuable, but let’s finish the project that’s been spec’d and revise that once its tested and acceptable to add additional features or to meet another need.” (Stolovich, n.d.)

 

Although the director of engineering would be as firm as he could about sticking to the original project request, it was often negated by the C.E.O. who felt that feature could increase sales of the product.  It’s kind of hard to say, “Next version” to the person whose name is on your check.  What worked well for a short time was the relocation of the entire engineering department to a separate location.  The day to day interruptions from marketing team members drifting in for informal reviews, manufacturing supervisors asking for test software changes to accommodate the electrical engineer’s new firmware, etc. were curtailed by the physical separation of the department.  The distance of the developers from the rest of the plant, ensured more focused time, but the culture of the company supported scope creep.  The customer was the most valued stakeholder and delivering a product later with their request incorporated outweighed any padding of the development timeline.

References:

 

Stolovich, H. (Producer). (n.d.)Project Management Concerns: ‘Scope Creep’. Laureate Education, Inc. Retrieved from https://class.waldenu.edu/webapps/portal/frameset.jsp?tab_tab_group_id=_2_1&url=%2Fwebapps%2Fblackboard%2Fexecute%2Flauncher%3Ftype%3DCourse%26id%3D_1373695_1%26url%3D

Welcome to Project Management for Instructional Designers. This blog is intended to share how the roles of the Instructional Designer and Project Manager influence the key factors and priorities that are considered during the initial phase of an instructional design (ID) project. Your feedback is encouraged and welcome.

Stay tuned to exciting information as we embark upon this eight week journey!