What is the correct way to handle delays caused by technical issues?

Question

I am working on a Web Design and Development project for my Final. I have missed Alpha and Beta milestones due to a critical server error that was beyond my knowledge or understanding. I had to get in touch with a qualified professional to help me rectify this error which took approximately a week and a half to address. I should note, at this time, I sat down with my instructor multiple times, and he could not understand the issue, either.

My instructors have been giving me a hard time about it, so I am trying to be as professional as possible, considering it had nothing to do with my code (which was fine).

What kind of paperwork is processed if this were to happen with a development firm? What is generally said at the meeting? How should I best address this? I have absolutely zero training in project management. I am simply working on my own project for a Final, yet I need to know how to handle myself as a project lead professionally in order to get my point across.

I would desperately like a piece of paperwork that documents the issue.

Answer 1

In traditional project management this would be covered by Monitoring and Controlling Phase of the project. This would most likely come out as part of a standard status report and be raised into the risk register as a blocking issue.

The key is early and accurate reporting. When the issue comes up, it gets reported to the project manager for the normal status. Because it impacts the delivery of the project, and there is no known resolution when it first come up, the program would be reported as red. The risk register would reflect the blocking Issue. An Issue being a risk that has been realized and is occurring.

In agile, this would have been raised as an impediment in a daily standup. Because it is beyond the developers control to address, the scrum master would have the responsibility to own it and work to a resolution. Normally this is by the scrum master escalating the issue to the appropriate organization. The impact would be reflected in the burn down chart, where the stories completed would not be what was originally committed. During the Sprint Demo this can be raised and explained to the stakeholders at the demo.

End of the day, there is no "smoking gun" document to use. My guess is your instructor is trying to get you to think about how you went about reporting and monitoring your issue. In today's work place a good software developer is part project manager, able to take ownership and action for issues. Did you report this as a blocker as soon as you knew? Did you provide regular updates on the resolution? Did you escalate with a clear request for action?

I'd recommend sitting down with your instructor and simply asking him where he thinks you could have improved on what you did. This will serve two things. First is it will let you know if he is aware of all that happened. Second, it shows you want to learn from your mistake (even if it really wasn't yours) and that goes a long way with pretty much ever teacher I've ever know.

Good luck!