David DeWinter

Throughout the majority of Quarter 5 at Neumont University, a team of us here at RevNet worked on a project known as Virtual Employee/Kahn for DesertGate. The main impetus for this project was a simple exchange of favors: the Revolutionary Networks team does projects for DesertGate in exchange for server space and some other benefits (the details of which I am not aware). Over the course of the quarter we worked on solidifying a requirements document to define the scope of the project, and the eventual goal was to take these requirements and run with them to create a solution that would solve their business problem.

But because of stifled communication between DesertGate and RevNet, the project was cancelled by the Project Manager and the Technical Lead. Although at first I was surprised and taken aback at the concept of actually cancelling the project, I took a few days to reflect on why we did so. I came up with the following:

1. We started this project in mid-July. It was now late August and the business requirements were still not quite done.
2. Even if we had finished the business requirements, user requirements would’ve been an extreme hassle to go through. Not only were we a state away from their office, but we really couldn’t solicit responses from users on their own time. The downtime between our sending questions and their responses would waste a lot of time.
3. On top of that we needed to know system requirements, which would take another set of questions through email…it goes on.

Only after that mess could we actually begin to design a solution that we wanted to - that’s looking at another quarter just to gather requirements! And that includes all the ORM for business objects, the use cases, the business process descriptions, possible business rules, UI design, interaction design, component design, technical specifications all before the actual development process starts. Even if we are being compensated with server space, we cannot afford to spend so much time idling on a project!

I also talked with a professor who prides himself on project management about this situation. What I learned from the conversation was that at that point in the project, to call it quits was not necessarily a bad idea. However, may be in future what would be better is to solicit more direct feedback from the company. Because one of the members of the project has worked for the company, he was assigned to be the product manager (the one who interacts with the client and ensures that the business requirements meet the solution later down the line) - it’s only speculation, but that could’ve caused DesertGate to feel more relaxed about the project and thus not rank it as a high priority. If we were being paid to idle, that’s fine, but having DesertGate consume our resources like this was just not cost-effective to the team.

That being said, if DesertGate does decide to clean up its act, then I’m sure our team would have no problems working with them. But perhaps we need to effect a change in how we communicate with outside companies. I know another member of our team who was not working on this project has stressed that communication isn’t really there unless it’s in person or over the phone. Maybe that’s a tenet we should incorporate into future projects with outside clients.