David DeWinter

I recently had a great opportunity to work on the Zee project with other members of the Revolutionary Networks team. This project flowed much more smoothly than the Kahn project, and I believe our efforts were phenomenal over the past couple of months. For those not familiar with Zee, the project aimed to deliver a learning management system targeted at students at Bridge Academy in Las Vegas, New Mexico. Although I have never been to Las Vegas, Josh Arnold attended the school and Ryan Abreu was also familiar with it. Not surprising that Josh was our PM and Ryan was a member of the team.

Unfortunately, the RevNet team got the news that Bridge’s unique approach to teaching students was not looked well upon by the school board. That, coupled with a few other issues, influenced the school board to vote against renewing the school’s charter; as a result, the school will be closing. I have not heard whether there are a lot of people protesting the closure, but I know there are some efforts being made to keep it open.

The sad thing is that if everything continues then the Zee project will have to stop. We made it through the requirements gathering and domain modeling phases and have a solid framework for continuing forward should the need every arise. But it looks more likely that work will not continue.

As we go forward, I think it’s important for everyone on the RevNet team to realize that even if our clients “disappear,” our work and our experiences are never lost. Even though this was a side project, we all accomplished a lot and have grown in our technical and interpersonal abilities because of it. Equally laudable is the fact that this was the first time that RevNet members worked collaboratively on a project from different sides of the country.

So if this is the final page in the Zee chapter, I say it was work well done. Congrats to the RevNet Team!

Update: Bridge Should Appeal To State

Looks like the academy can appeal, and I hope they do…

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.