Supplier Group #1
Project Evaluation


  • What if this had been a real project?
  • Management Plan Evaluation
  • Test Plan Evaluation
  • Lessons Learned
  • Back to the Supplier Group #1 Home Page.

    The Good (What went right):

  • Fortunately, we all seemed to get along with one another, and we seemed to avoid any personality conflicts which could have had a detrimental effect on our progress. The members of the group usually communicated well with one another.
  • The members of the group had a high level of commitment to the project, so everyone did the work assigned to them. With the exception of losing a group member and not finding out until weeks later, people finished what they said they were going to do. It was good to know that we could depend on people, since one person messing up would have reflected poorly on the entire group. Despite the fact that each of us had a different schedule and other commitments outside of this project, meetings were well attended, and we usually had little trouble finding time to work on the project.
  • Everyone stayed involved throughout the project. Since almost everyone was involved to some extent in each phase of the development, we didn't have to spend a lot of time familiarizing people with recent developments.
  • The loss of a group member didn't slow us down. The remaining members managed to pick up the slack and make up for the missing person.

    • The Bad (What went wrong):

  • The group lacked clear leadership and structure. We had a wide range of different skills and talents in the group, but unfortunately we had no one who took charge immediately. There was no one in the group who seemed comfortable assigning work to others, especially since all of the group members were essentially equals. It may have been a good idea to choose a leader, although it seems unfair to thrust leadership upon a reluctant victim, and a reluctant leader may have been worse than no leader at all.
  • Sometimes people were reluctant to volunteer for tasks. Again, having a leader to assign tasks would have been good. This may have ensured that the workload was spread more evenly amongst the group members.
  • Lots of redundant or unnecessary documentation. At times, we felt that meeting the length requirements for certain documents meant that we had to pad our documents with information that wasn't really necessary or appropriate. The time spent adding to the documentation might have been better spent doing other things.

    • The Ugly (What else happened):

  • Microsoft Access was a tough choice for our programming environment. It is quite easy to learn and we already had one group member with extensive experience in Access as well as a couple of others with some experience. In addition, the project we were presented with was a typical business system, which is the type of application MS Access was developed for. That is to say it had strengths as a relational database and enabled rapid application development.

    However, since a lot of the early design documentation was dependent upon the platform and software choosen, it was difficult for people without experience with Access to accurately describe the system. In several instances subgroups would be designing an individual module, and while they knew what the module would need to do they were unsure as to the way this would be implemented in Access. This added to the workload of those people already familiar with Access. It probably would have been a good idea for several or all of us to have spent a few days getting acquainted with Access at an earlier point in the semester. This way we may not have had to be quite so dependent upon the ones with prior knowledge. Although, with the pace of the course, and other academic and external pressures on the group this seems a very tough road to travel.

    It should be noted that due to our group's diverse skillset in relation to development platforms and software packages, it was exceedingly difficult to find the "right" tool for the job. Some members had TCL/TK experience, but with no relational database to support it, and no graphical interface builder, using it would be a far larger chore than with MS Access. Of course using C (which all members of the group knew), was accompanied by bitter warnings from past groups about the complexity of the implementation. Several other packages were mentioned, such as Foxpro or Paradox, but eventually MS Access seemed to be the lesser of the evils.


    • Completion of the Original Requirements

    For the most part, the final product adhered to the original specifications. Most changes to the requirements took place in the first couple of weeks, and after this point both the supplier group and the customer group seemed to be in agreement as to what the final system should do. The customers expressed satisfaction with the final product, and we believe that not only does it meet the requirements, but it accomplishes the objectives in an efficient and intuitive manner, all wrapped up in an attractive interface.

    Changes to the Original Requirements

  • The original specifications did not include the division between administration functions and salesman functions. Administration functions include many of the things that would need to be part of a real system, such as inventory tracking and things like that, but these features were outside of the scope of this project.
  • We adapted the original method of determining the optimal route list. Rather than calculating the shortest route that would visit each point, which would have required knowing the geographical location of each client, we divided the region into a number of sectors. When a new client is added, it is assigned to a sector. When the route list is produced, the sectors will be visited in an optimal order, but the routing within the sector is left to the discretion of the salesperson.
  • No changes have been made to the the project specification since the presentation and contract signing. (One minor feature, the inclusion of customer comments on the route list printout, was overlooked, but this feature could easily be added to this version of the system.)

    • What if this had been a real project?

    Many things would have been different if this had been a real (commercial) product. In some ways the nature of this project sheltered us from some of the realities of the business world, but in other ways a real project would have been designed to get the most out of each member of the development team.

    Group Structure

  • A company assembling a team to develop a product like this would assign roles to the group members, and would not pick a group at random and send them off on their own. Specifically, the group would have a predefined leader, and probably would consist of specialists in each aspect of the development, such as technical writers, programmers, interface designers, and so on. In a group like ours, where many of us don't really know our own strengths and weaknesses, let alone everyone else's, it was difficult to get the most out of each person.
  • Along with a defined hierarchy within the group would come different levels of responsibility. The people in charge of the project would have more at stake than most of the people working under them, and also would probably be compensated accordingly.
  • The same people would not always be working on the project. There would probably be a small subset of the team which would be involved with the project from its beginning to its completion, but along the way there would probably be people added and removed as they became needed. The people who gather the requirements would probably not be the same people who write the code, and it might be an entirely different group that does the documentation.
  • It may be the case that the people working on the project would be more committed to the project, without the external conflicts of other classes, other jobs, and so on. However, people working on a real project would still have to function in society, and it is very unlikely that anyone would be completely focused on a single project.
    • Development Environment
  • We probably would have used a language that everyone was more familiar with. It is likely that most people would not even begin working on the project until after the programming language had been selected, so that people working on the project would be chosen based upon their experience with the language. It is unlikely that almost all of the people would be simultaneously learning the language for the first time and developing a system with it.
    • A Real Customer
  • Of course, a real project would have a real customer with real needs. The customer's needs would probably change as the project progressed, so we would have to be prepared to alter the system accordingly. Unless the changes were large and difficult to implement, it would be unrealistic to tell the customer that the changes would be impossible, and we probably attempt to accommodate the changes without rewriting the contract.
  • A real customer would have real experience. It was difficult for the customers to communicate their ideas and requirements to us when they did not have any hands-on experience with the process that we were attempting to develop a system for.
  • A real customer would come from a different background. Since the customers for this project were also computer science students, we were able to communicate with them on our own terms. In a real situation many of the ideas that we take for granted may be completely foreign to the customer, so we would have to communicate with them on their terms. At the same time, we would have to be familiar enough with the customer's environment so that they would not have to define their specifications in terms that would be easy to translate into a computer system.
  • A real customer would probably be more available during the development process, and might take a more hands-on role during development. In several cases we required specific answers from the customers, but since they were not really the travelling salespeople that they were pretending to be it was difficult for them to give us a realistic answer.
  • A real customer would pay us if we completed the job. We have yet to see a single penny from BFI, and there seems to be no indication that we will ever get paid for our efforts. If such a situation arose in the real world we would be able to use the legal system in order to ensure payment.
    • More Extensive Testing
  • Since a real project would eventually have real users, we would have placed more emphasis on developing a system that not only does what it is supposed to do, but does it in an efficient way. There was not a lot of time to test the system with real users and perform any extensive usability studies. The product would certainly benefit from comments from real users who had experience with the real system and have a clear idea of what they will have to do with the new system.
  • Use of prototypes. More regular contact with the customer would have allowed us to use different methods, such as storyboards and prototypes rather than extensive text documentation, in order to allow the customer to experiment with different ways of implementing the system. It is easier to get pertinent feedback from future users if they have an opportunity to actually work with the interface, rather than just reading about it.
    • An Ongoing Project
  • It is unlikely that the project would end with delivery to the customer. Bugs would probably appear occasionally, and revisions would probably be requested. Hopefully the client company would be successful and would expand, so it might be necessary to modify the program in order to deal with these changes. With this in mind, we probably would have had to design this program in such a way that it could be included as a part of a larger package. Since we knew that this project would end with the end of the term, it is possible that we compromised in some areas where a little more work may have resulted in a more robust system. In other words, we would have had to focus more on the long-term life of the program, rather than just the short-term completion of the project.

    • Management Plan Evaluation

    Our management plan worked quite smoothly, but since collectively we had little experience working in a group of this size there were areas where we had to stray from the original plan. The structure of the program itself which we specified in the management plan was followed, and so the plan was useful to us in this regard, but the way in which we planned to divide work and handle individual submissions turned out to be quite different from reality. Now that we have more experience with working in a large and diverse group, we could probably put together a relevant and useful management plan that we would be able to follow.


    Test Plan Evaluation

    The test plan wasn't followed as rigidly as we had specified. Some of the modules were completed earlier than expected, and extensive testing of certain things was not necessary because it would have been impossible to implement them in the first place without them working. Several people worked with the program and made helpful observations and suggestions about things like unclear messages, inconsistencies, and so on. Since MS-Access takes care of some of the problems that we could expect if we were working in a language such as C and makes the interfaces between modules somewhat simpler, much of the testing described in our testing plan wasn't really applicable. For example, there isn't a compiler to catch many of the errors, but it is still necessary to explicitly ensure that each button does what it is intended to do. Again, since the test plan was written primarily by people with little experience in Access, it wasn't as relevant to Access as it probably should have been.


    Lessons Learned

  • Clearly define a group structure early in the project. This would probably include choosing a group leader, and possibly breaking down the group into smaller subgroups. It is very inefficient for the entire group to participate in each aspect of the project, and meetings of the entire group are often long and tedious. Smaller groups are better able to find time to meet.
  • Make sure that as many people as possible are familiar with the chosen programming language. It should be possible to choose a language fairly early, so if only a few people know the language the rest should attempt to gain some experience with it.
  • Define standards for formatting documentation. Since it is impossible for one person to do all of the documentation, several people will be contributing to each document. If each person uses their own set of rules then the editor will have to do a lot of extra work to combine the sections into a consistent final form. It creates a lot of wasted time if several people have to write and rewrite the same thing.
  • Set a structure for meetings. Regular meetings may be necessary. Free form meetings are a bad idea. There should be an agenda so that everything that needs to be discussed gets taken care of, and everyone knows what they need to do to prepare for the meeting. After the meeting everyone should be aware of their responsibilities.
  • Set deadlines and stick to them. Since many parts of the project pass through several sets of hands on their way to completion, it is essential that each step along the way is reached on time, or else the entire project could be delayed. Make sure to allow flexibility in case of emergency, however.
  • This project proved to be a good experience for us. Most of us didn't have much experience working in a group of this size, so there were lots of unanticipated problems that arose. As the project progressed we became more adept at dealing with these problems.

  • Back to the top of this page.
  • Back to the Supplier Group #1 Home Page.