Looking back at some of the projects that I participated in, trying to recall any project that stuck out in my mind. I recalled working on a project, where I was to design training products that were flexible and compact, that could be used to support a mobile training team. The project time line was unique in that both teams; Software Designers and Instructional Systems Designers (ISD) where to work parallel both moving in the same direction with what seem to me to have limited and at times no interaction with each other. To stay on track for our part of the deliverable, my team was tasked to created training products for what might be the final system. As you probably gathered we spent a lot of time with rework, making corrections to training products that were affected by system design changes, always at the last minute. But this was expected due to the way the project as whole was run. As the software team felt they had a stable section they would notify our team to go ahead and prepare to deliver its training products. The problems came for me, when evaluating my design, checking my training products to ensure it still matched the actual system. I would always be the lucky one to discover that they don’t match 100%. The products were designed to teach button functionality for the system according to the system design blueprints provided but as I discovered that wasn’t always the case or there were more buttons. The best was trying to explain this discovery to the testing team (sub-level of the system designers team) who just approved the section (dealing with it’s not my fault) and recommend that they go back now not after the approval is accepted and check my findings. To my surprise I found out that we didn’t have the authority to make changes. The reason as it was explained, we didn’t write the program another team was responsible and the process to make changes with them was painful. As I thought to myself you took an hour of my time to finally admit you weren’t going to do anything and worse you are still signing off as accepting the other teams work as sound, turning an eye to this mistake. As it was explained this happens at times when working with software projects and the work around is we get them back during the change process where we have more time under a different milestone.
Looking at this project from an analytical perspective it was structured with three independent mixed organizations. Each company was structured with VP’s, group PM’s, section managers and their sub contractor’s PM, all connect at the top with client. (Portny, Mantel, Meredith, Shafer & Sutton, 2007, p 69) Although I didn’t see any one’s statement of work, from what I gathered its wording came from lawyers and high level VP’s/PM’s. Each group’s PM creating SOW at a very high level to support their bids for the high dollar value of the project. Another observation was during meetings where majority representation from each teams (same company/w/sub contractors) were present, it seen as if there was an atmosphere of tension between some team leaders/members, for my team a feeling that they considered training to have no value within the process simply because we didn’t have approved software to design training from. In the end ISD and other teams whose task responsibilities were preformed in the last phase were release to save money during the rebidding of the contract. At this point I would consider the project successful but not perfect; they did win the next contract but determined that they should wait the next go around until the software was approved to develop the training products.
I don’t know if the process or concept of PM works differently for smaller companies than in larger companies with high dollar projects but I suspect that it’s just more complicated for larger projects? What I would possibly do differently is to:
1. Provide a more interactions between the teams; e.g., testing and ISD. (Portny, Mantel, Meredith, Shafer & Sutton, 2007, p 67)
2. Develop, document, and distribute to all team members a better process plan on how each team is to interact and address issue between them with the PM. (Portny, Mantel, Meredith, Shafer & Sutton, 2007, p 67)
3. Provide all team members a matrix to let everyone know how each team interface with each other and where they are located. (Portny, Mantel, Meredith, Shafer & Sutton, 2007, p 67)
4. Document (outline) every teams role and responsibility within the project to include the project time line. (Portny, Mantel, Meredith, Shafer & Sutton, 2007, p 67)
I don’t know if this is possible but I would have tried to be more a part of the development of the SOW and the agreements between the three different companies (their SOW and roles), to ensure that there was a clear and easy process to deal with program error, function issues etc. (Portny, Mantel, Meredith, Shafer & Sutton, 2007)
Reference:
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.
