Page Last Updated Sunday, April 27, 2008 10:13 PM

Project Title

ePharmacology

Project Manager

Jerry Bates

Project Team

Ray Chapman, Angela Macklin

Sponsor

Dr. Michael Grant

Date

April 28, 2008

Project Evaluation Report

Project goal

This project will design, develop, test, and deliver a new on-line drug pronunciation performance system populated with a representative set of drugs that can be maintained by the system owner.

Project objectives and results

Product specifications and critical success factors

Result

  • A database of generic drug names, categories, subcategories, descriptions, brand names, phonetic spellings, and audio pronunciations. 
  • A database with two tables was created.  One contains the categories, and the other contains the drugs.  The record in the drug table includes all the specified fields.  The database was created using MySQL.
  • The database must be accessible to the users through a Web interface, which is neither platform nor browser dependent.  This interface must be intuitive and easily navigated.
  • Data in the database is dynamically available to users using data connections scripted using the open-source PHP hypertext preprocessor which delivers the user-selected content to the html Web page.
  • The web interface was successfully tested with Firefox, Internet Explorer, and Safari browsers, and on both the Macintosh and Windows operating systems.  Formative evaluation results indicated the interface was intuitive and easy to navigate. All the information in the database is dynamically available to the users through the Web interface.
  • The user must be able to access a drug name by its category and repeatedly play an audio pronunciation of the generic name for the drug, through the web interface.
  • Users can select a drug name from a list which is sorted by the categories, and use the audio control displayed on the web page to activate an audio pronunciation of the generic name of the drug.  Formative evaluation results demonstrated the system permitted users the replay the audio file as needed.
  • The product must be initially populated with 90 drug names.
  • The system is populated with the complete list of Autonomic drugs, which is the category selected by the client.  This general category contains subcategories, and within the subcategories, a total of 89 drugs.
  • The product must support expansion to a comprehensive list of drugs, which at present contains 700 drugs.
  • The system can accommodate virtually unlimited expansion to the database. The team has pre-loaded these additional drugs into the database, at the client’s request.  All that is left for the client to do is add the audio links and the phonetic spellings for these additional drugs.
  • The product must be able to accommodate video clips (provided by UTHSC) which UTHSC plans to add at a later date. 
  • The record structure in the drug database contains a field for the address of a video file; a directory for the video files has been established on the client’s host server; and the user interface includes a location to display the video clip.  Testing confirmed an interactive video control displays and works. A generic Flash video was also included and displays a placeholder “video not yet available” message.
  • Audio files for the pronunciations may be derived from video files provided by UTHSC, retrieved from authoritative external sources, or recorded by new subject matter experts.
  • Eighty of the 89 audio files were sourced from the University of Maryland Medical Center’s Complementary and Alternative Medicine Index (http://www.umm.edu/altmed/) which licenses the content from A.D.A.M.com (http://www.adam.com).  The remaining audio was recorded by the project team, using an R. N. from the University of Memphis’s Student Health Center.
  • The site must be designed to conform to and use the UTHSC Medical Library server specifications: OS X (10.4), 250 GB storage, 2GB RAM, php 5.0 (minimum), mySQL 5.1 (minimum), SQLite 3.0 (minimum), support for SSH/SFTP, 10/100/1000 ethernet adapter, and Linux based system. 
  • The product is fully compliant with the specifications of the client’s web host.  As delivered, the system uses 1,322 kb (1.3 megabytes) of storage. 
  • Estimated future local host storage per audio file is 76kb; for video file is 45kb per second.
  • The system will be hosted by the UTHSC Library and will not require a user login. 
  • System maintenance documentation must be included with the product to delineate how to add, change, and delete database entries. System managers will have access to the system to conduct needed maintenance.
  • A printed job aid with screen captures was produced together with written instructions on how to maintain the database.  A hands-on training session was conducted with the sponsor to provide practice in accessing and maintaining the database.  Access to these functions is restricted to validated user name and password provided by the client’s web administrator.
  • Learners will perceive the system as useful in helping them learn to correctly pronounce drug names.
  • Survey items in the formative evaluation phase indicated users perceived the system useful for learning to correctly pronounce drug names.
  • NOTE: The product was originally Pharmaco-Phonetics.
  • Name simplified to ePharmacology.

 

Scope comparison

To compare the planned and actual scope, the project manager prepared an initial draft which was reviewed by the database designer who concurred with the analysis and corrected the technical descriptions.

Planned Scope

OpenJAR planned to:

  1. Create an online system that presents drug names together with their audio pronunciation.
  2. Use public domain database software for the system.
  3. Deduce the appropriate record structure for the database after analyzing the hierarchical structure inherent in the provided drug list.
  4. Create the drug records beginning with the high priority items specified by the client, using 30-50 drugs as the minimum number, and accommodate up to four brand names for each generic drug name.
  5. Acquire, catalog and store audio pronunciation files for the drug names.
  6. Employ the following priorities for the audio sources: (1) new audio recording, (2) existing audio recordings located from third-party sources, and (3) renderings from existing video provided by the client.
  7. Depending on available resources, locate existing phonetic spellings for drug names and add them to the drug record. (e.g., Hydalazine = hye DRAL a zeen)
  8. Design and create a web-based interface so learners can access the system from the network.
  9. Design a user interface to support learner-selection of drug names for practice.
  10. Provide on-screen controls for the learner to activate the audio file.
  11. Develop the prototype using a development server that is separate from the client’s system.
  12. Collaborate with the client’s IT representative to install and test the new system on the client’s server.
  13. Create a system maintenance job aid for the client’s IT representative.
  14. NOT include all 692 drugs originally provided by the client.  Instead, the project will deliver 30-50 drugs, based on the prioritized list provided by the client.

Additional Scope

The following elements were added to the project scope:

  1. The client identified the Autonomic drugs as the priority list.  The number of drugs in this group (89) exceeded the original scope, but was necessary to meet the client’s prioritization.  Audio and phonetic spellings were provided for these 89 drugs.
  2. In addition, the complete list of 692 drugs were preloaded into the database, per client request.  This includes the category, drug name, treatment area(s), and brand name(s) for each.
  3. At client request, database and interface capacity supporting client’s future addition of video clips was added to the system.  A Flash placeholder for the video clip was also created and linked in the database.
  4. An external source for additional audio files was located, which the client may link to add audio capability for the remainder of the drugs in the comprehensive list.

Decreased Scope

  1. Due to the time constraints of the class, and the estimated time required to copy the video tapes, it was not possible to use the original video tapes as a data source for the audio pronunciations.  Instead, an alternate web source was identified, with links to the audio clips incorporated into the system.  For those drugs in the Autonomic category not found in the external source, local talent was used to record new audio files.  Phonetic spellings for those drugs were located elsewhere.
  2. Hosting the development product was initially attempted on a host server separate from the client’s system.  However, data connection issues prevented the use of this host.  Consequently, access to the the client’s host server was requested and received, and used to test the development product.  Development utilized a WAMP server installed as a local host, MySQL for the database, and AJAX (asynchronous JavaScript and XML) to connect the data to the web interface.

Cost performance

Using the time budget projected in the original project charter, the following comparision of budget to actual was conducted. 

Project Team Personnel

FTE Time in Project Charter

Budgeted Hours
Actual Team Hours
Over (under) budget
% of budget
Ray
Angela
Jerry
Total

Video/audio technician (copy/convert/ videotapes)

30

8.00

 2.00

 

 10.00

        (20.00)

33%

Editing and cataloging video files

20

 

 

 

 

(20.00)

0%

Database design

20

10.00

 

7.50

17.50

 (2.50)

88%

Website interface design and testing

60

79.50

3.00

22.75

105.25

45.25

175%

Team member cross-training

20

 

 

 

 

 (20.00)

0%

Project analysis (includes context, learner, performance, learning context, and goal analyses)

40

1.50

12.50

36.75

50.75

10.75

127%

Content analysis

15

 

 

7.00

7.00

(8.00)

47%

Instructional Strategy

15

 

 

 

 

(15.00)

0%

Treatment design, template, and storyboard

30

 2.00

 

3.75

5.75

(24.25)

19%

Treatment Report

15

 

 

7.23

7.23

(7.77)

48%

Formative Evaluation and reporting

20

 

8.00

19.58

27.58

7.58

138%

Document creation/duplication

10

 

 

 

 

(10.00)

0%

Job aid production for UTHSC system manager

15

16.00

 

 

16.00

1.00

107%

Project management, communication, and meetings

140

27.00

24.00

 86.00

137.00

(3.00)

98%

Total

450

144.00

 49.50

190.56

384.06

(65.94)

85%



External costs


Cost Categories

Budget

Actual

Over (under) budget

Labor (in hours for consultants, contract labor)

 

 

 

Outside talent to pronounce drug names

2

1

(1)

Formative evaluation participants

8

4

(4)

Subject matter expert to review and prioritize lists

3

2

(1)

Total

13 hours

7 hours

(6) hours

Equipment, hardware or software

 

 

 

AIM Lab recording and processing time
(estimated 32 hours @ $5/Hr = $135; contributed by U of M ID&T Department)

$135.00

$ 40.00

($ 95.00)

WAMPserver, PHP, and MySQL

-0-

No charge

--

Creative Suite 3

-0-

0 (free 30 day trial)

--

Prorated cost of development server at ed-u-cate.org

-0-

$ 27.96

$ 27.96

Travel and Training; installation and training; formative evaluation reviews; meetings with client at UTHSC (mileage costs at federal rate of $0.505/mi)

-0-

$ 62.87

$ 62.87

Paper for job aids (1 ream at $4.50 estimated)

$4.50

$ 4.50

--

SurveyMonkey monthly charge for needs analysis; project followup: 2 months at  $19.95/month

-0-

$ 39.90

$ 39.90

Color copies for job aid

-0-

$ 40.00

$ 40.00

Total

$139.50

$215.23

$75.73

Summary of budget to actual cost performance

As these results show, team time came in at 85% of budget overall, but there were notable exceptions in individual task areas.  Specifically, website interface design and testing (175% of budget), formative evaluation (138%), overall project analysis (127%), and job aid production (107%) required more time than anticipated. Savings were realized in the areas of video tape processing, team member cross-training, and development of instructional strategy.  This latter savings was realized because there was no instructional strategy to develop in a performance support system.  The treatment design also required less time than budgeted, but if more prototypes had been generated, the process may have approximated the budgeted time.

External costs also varied from the budget.  External labor costs came in under budget.  AIM Lab costs were also under budget, due to the fact that the original plan to process video was not pursued.  Additionally, there were project cash costs for the project.  Of these, only the paper for job aids had been factored into the original budget.

Schedule performance

 

Estimated

Actual

Project completion date

April 21, 2008

April 21, 2008

Explanation of schedule variance:  The product was delivered on time.  However, from a time perspective, the project was over budget.

Process perspectives

An online survey was developed during the April 20, 2008 team meeting to ask questions of each stakeholder group.  Distributed via email on April 21, 2008, the survey was closed on April 27, 2008.  Responses were received from all three team members, the instructor, one of the two eLearning experts, and the primary client.  Responses used a 5-point Likert-style scale with 1=Strongly Agree to 5=Strongly Disagree. Survey results are shown in Table 1.  Results disaggregated by respondent group are available in the Appendix.

Table 1: Process Perspectives Overall Results  

Category: Question

Overall  Mean Response*

Instructional Design

 

The product met the original proposal expectations.

1.67

The product met the terms of the proposal outlined in the team's project charter.

1.33

The design process successfully identified the essential element(s) for this performance support system.

1.67

The ePharm website follows a logical order.

1.17

The ePharm content is at a level appropriate for the end user.

1.17

The database management job aid follows a logical progression.

1.50

The database management job aid adequately addresses the need for which it was requested.

1.50

Instructional Design Summary (Agree to Strongly Agree) 

1.43

Development Process

 

Rapid prototyping was an effective process for developing this project.

1.50

The Open JAR team effectively utilized the rapid prototyping process.

2.00

I had adequate opportunity to provide feedback to the product during the development phase.

1.67

Changes to the product were implemented in a timely manner.

1.50

Product revisions appropriately reflect formative evaluation findings.

1.33

Development Process Summary  (Agree to Strongly Agree) 

1.60

Project Management: Communication

 

Overall, communication with me was conducted in a timely manner.

1.67

Overall, communication with me contained the information I needed.

1.50

I believe my input to the project was given careful consideration.

1.33

From my perspective, the right type of communication (email, face to face meeting, phone) happened at the right time.

1.80

Project Management: Communication Summary (Agree to Strongly Agree) 

1.58

Project Management: Roles and Responsibilities

 

I was able to contribute my knowledge and skills to the development of the product.

1.83

I knew what was expected of me during the development process.

1.50

Project Management: Roles & Responsibilities  Summary (Agree to Strongly Agree) 

1.67

Project Management: Time Management

 

The project's intermediate deadlines were met.

1.83

The project's final deadline was met.

1.33

The timeline outlined in the project plan was appropriate for a project of this scope.

2.33

The timeline outlined in the project plan was realistic.

2.50

Project Management: Time Management Summary (Agree) 

2.00

* Range: 1=Strongly Agree to 5=Strongly Disagree  

 

In addition to the Likert-style response items, two open-ended questions were included in the survey.  The following comments were collected.

Survey Open-ended Response Items

Respondent group

What are your general impressions about the overall process involved in the development of the ePharm product?

TEAM

  • (no response)
  • Although the project is in its final phases, I feel that it is important that the team gets together to discuss how everything was "put together".
  • The process was rocky at times.  In my opinion, this was due both to skills needed to develop the project we bargained for when we selected this project (and didn't realize we didn't have), and to incomplete communication (both within the team and with our client).  We were learning how to deal with a client, how to manage a project, how to create a database, how to design a web page using style sheets, what EPSS actually was, and how to negotiate differences between the development process scheduled in the course outline and the detour we had to take to try rapid prototyping, a process we really had little experience using.  Working as a team was also very challenging, especially when it came to knowing who would take care of what elements and which components we could effectively share.  I'm not sure we navigated that area very well.  However, we DID produce what we outlined in our charter, and we did deliver it on time.  On budget?  Jury is still out on that, as we still need to get an accurate picture of the time involved.

CLIENT

  • I would have liked more f2f meetings and some notion of what the product was looking like.  Even non-functioning screen shots would have helped.

EXPERT

  • I don't know enough about the inner workings of your team and process to comment with much depth, but the fact is you produced a working product, and the client seemed satisfied.

INSTRUCTOR

  • I think it became evident that your time estimations were grossly estimated given that your team did not originally possess the skills necessary to produce the product.  This would, of course, improve in the future with estimations and with development of this kind.  I believe the rapid prototyping approach was successful for functionality, and future projects would benefit from other types of prototypes, such as layout and design.

 

Please provide any suggestions you would like to offer us for improving our process.

TEAM

  • Everyone needed to be involved in the development process.
  • (no response)
  • -Communication is critical.... Our communication plan did not seem to be a living document.  -Meet with our client to review each documentation piece in turn, to better judge its reception.  -Start earlier on graphic design pieces --to both get outside help and feedback from the client.  -Hindsight is 20/20.  Was this a good project for our existing skill set?  Or it it require too big a reach beyond our grasp?  -Realistically find out your team's talents before signing up for a project!

CLIENT

  • More.

EXPERT

  • You did a good job.    On some questions I answered "neutral" because either I didn't know, or it wasn't applicable to my role in the project.

INSTRUCTOR

  • Consider how much time was added in order to learn to produce your product.  Consider how much time was required to produce a performance product v. what you would consider necessary for an instructional product.  Are there ways you could decrease the development time you had?  Are there ways to do more of the project tasks concurrently?  Are there ways to increase accountability among team members and increase communication?

 

Lessons learned

Group Discussion (April 20, 2008, team meeting with Jerry Bates and Ray Chapman)

  • We experienced some isolation in executing our particular responsibilities.  We solved it by reaching out to team members and asking for help.  Part of this was inevitable because we capitalized on the skill sets of individual team members, but we had to learn to reach out for help.   Some of these people included other team members, Dr. Grant, Matt Grayson (at UTHSC), JongPil Cheon, and various user groups on the web.
  • We discovered that some technical issues take care of themselves (due the dynamic nature of of web applications). (Example: the press spacebar message)
  • Communication among a team composed of people with various work schedules, varying access to email, and other responsibilities can pose a challenge.
  • We encountered various technical complexities which posed challenges.  For instance, the developer machine encountered the “blue screen of death” while others’ computer spent “time in the shop.”  Running a backup or burning a CD for archive purposes was a necessary safety measure.  This applied to the course website, individual work files, as well as the end product we were developing
  • In terms of activity duration and cost, once we decided we weren’t doing any video editing or all 700 drugs, and not rerecording any drugs, that cut our time considerably.  We came in under budget because we were creative.  On the other hand, it took much longer to establish a data connection between the database (which was easy to build) and the website.  This is located in a “Connections” folder on the UTHSC library server.  If UTHSC removes us as a user of the database, they will need to change the php file in Connections folder (created by Dreamweaver), in addition to generating their own username and password.
  • Regarding relationships with clients, we found Dr. Brescia to be a man of few questions, although he was adamant about the video part, and this somewhat strained the relationship. 
  • We learned early on what we were capable of delivering, and built this into our charter’s constraints: they wanted 700, we promised 50, and we delivered 79 (11% of the total request, but 158% of our charter).  The core deliverable was a functioning database, which could accommodate as many drugs as they wanted to add or as their server would hold.  We delivered audio on a client-selected subset of the complete database. 

Individual Lessons Learned

The following reflections were submitted via email on April 27, 2008, by each member of the team.

Submitted by Angela Macklin

  • First, I feel like Dr. Grant wanted each of us to work on each section together to learn how to do them.  This is something that we really did not do.   Second, another lesson learned is that if you don't have all the skills needed to complete a project be ready to learn.  Don't be afraid of taking on a project.  This is an opportunity to learn new skills.  If you have not handed over the project to the client, I was thinking about the space at the bottom of the Illustrated Guide page.  Maybe under the title we could create a Flash object that has some pills scrolling across or several pill pictures changing after a few seconds.

Submitted by Ray Chapman

  • Technical
    • Initially I felt that I would have no problem getting the database to communicate with the website.  In the past, I have worked on IIS, MS Access type databases and had no problems.  However, working with SQL and Linux posed a challenge for me.  Reflecting upon this experience, I am glad that I was able to learn something new and possibly use how I was able to create the connection in other project.
    • Although I often times tell others that they should backup their data on their PC, it is a practice that I sometimes overlook.  Due to the several instances of the “Blue Screen Of Death” on my laptop, I have learned that I should practice what I preach and backup data on a regular basis.
  • Team
    • Working as a team has been a very interesting concept for me.  Many times, as I have worked on project, it has been an individual effort.  I have learned that everyone on the teams needs to have a somewhat active role in each component of the project.  As a team, I felt that we did not do as good of a job as we should have in letting each other in on what we were working on due to time constraints.  I tend to work better on my own and I perceived that it was time consuming to stop what I was doing in order to bring others up to speed, as well as, vise versa.
  • Communication
    • I have learned that not all communication is effective communication.  Although we agreed to utilize the Zoho Projects website, I eventually found it as ineffective.  Communications in a more direct manner (i.e. email, phone conversations, face-to-face meetings) were a more effective means of communication and would be my preference in the future.
  • Instructional Design
    • In the design of our project, we did not use any of the information that I have learned in instructional design.  Our project was one of those instances where there was no instruction.  This has taught me that not all instructional design will be instructional.
  • Project Management
    • The first lesson learned for me as it pertains to project management is that one should know their capacity.  I felt that it would be an excellent opportunity for me if I was the project manager, however, with my wife expecting our second child, I knew it would have been too much of a challenge for me.
    • I have also learned the importance of planning out your project prior to starting.  In the past when I have worked on projects, I generally did not have a plan.  The planning phase of project management allows an opportunity to outline all of the tasks necessary to complete the project, as well as, outlines a timeline in which those tasks should be completed.

Submitted by Jerry Bates

  • I found the responsibilities of “project manager” very challenging to navigate. It was difficult for me to determine exactly what that meant, although the team told me it meant keeping the project going to make sure we met our deadlines and encouraging everybody.  Serving as the point person communicating with our client was another challenge.  When a team member was working on a particular portion of the project, I felt it was more straightforward for the individual to discuss this directly with Dr. Bresica, and then report back to the rest of us.  For the most part, I think this worked rather well.  Lessons learned? It is important to have a clear outline of responsibilities or some established method for negotiating them in real time.  Perhaps the experience of this course will help inform that future experience.
  • Having some method of keeping track of where you are in the overall scheme of product development is very important.  At the beginning of the course, I spent time reviewing the resources Dr. Grant shared, and trying to get the project management tools in ZOHO set up.  While we used the forum feature and tried posting documents to share, those aspects never seemed to “click”… they were more of an exercise than actually facilitating the work.   Lessons learned? Get more practice using the tools you need before you actually have to press them into service.  Be wary of trying to fit your project process into some abstract structure that you do not adequately understand.
  • When faced with having to come up with a budget for the project, I personally had no idea how much time anything would take.  So having to create a labor budget for the project plan was an exercise in fiction.  Was it worth writing that short story?  The value really was not obvious until the time came to compare our actual time to the estimated time.  Curiously, we came in under budget in terms of time, although it certainly felt to me as if it was taking much much longer.
  • The database I created to keep track of my time turned out to be a very useful tool for me.  If I were to use it for another project, though, I would make sure the time categories fit the project rather than adopting somebody else’s schema for the classification system.  At the start of the project, though, I had no good idea of what categories would be useful, so using somebody else’s idea was a starting place.  Lessons learned? Continue to finetune a time keeping tool but keep it aligned with reporting categories (i.e., estimated time categories in the budget document).
  • Spending time learning how to create a site style sheet is well worth the investment.  While we put together different storyboards and visual templates, it wasn’t until we had our database connection working that we could flesh out the web pages.  This was very late in the game, and using a site-wide stylesheet helped with that process.  Next time? Invest time in designing the interface elements and use dummy content so you can get feedback from stakeholders.
  • When our team started this project, I was the only one who had not created a survey with SurveyMonkey.  So when the time came to collect process perspectives for this evaluation report, I was eager to catch up to my team mates.  It did not take long to get a survey posted, and the “analysis” feature was very useful.  We used a Likert-style scale.  I discovered that the values stored for the responses were in the order of the answers.  So, since we put “strongly agree” as the first response, that answer was stored as a “1”.  If I were to do it again, I would reverse the response categories so the most favorable response would have the highest value.  I wanted to chart the mean results, with highest value representing most favorable response.  Next time, I’ll know better.
  • I felt our team took a leap of faith when we selected this particular project. I was eager to learn how to create a web interface for a database, knowing full well that I had no skill in this area.  Unrealistically, I thought I could learn how by shadowing our team expert.  Time pressures made that impossible, as we had to be working on other parts of the project as those pieces were being developed.  There were times when I questioned whether we would be able to deliver.  But I learned that people have an incredible capacity to push ahead and learn new things in the face of very tight deadlines.  So despite sometimes thinking we had been foolish to choose this project, I am proud that we accomplished what we did.
  • This was my first exposure to the “rapid prototyping” approach, so using an approach I was not familiar with was an adventure.  Next time?  Do not be afraid to share the intermediate products with stakeholders, and engage them in conversations about where you are. 
  • Another “first” was the creating a performance support system.  Up to this point, my projects have been instruction in a knowledge-based domain.  Many of the protocols used in those projects were redefined for this project.  Lesson?  There are variations on the theme of “instructional design.” Being successful in this field means being open to new procedures and being able to transfer and adapt your skill set to new situations.

Appendix

Process Perspectives Survey Responses

(Response scale: 1=Strongly Agree, 2=Agree, 3=Neutral, 4=Disagree, 5=Strongly Disagree)

Category/Question

TEAM

TEAM

TEAM

CLIENT

EXPERT

INSTRUCTOR

Mean

Instructional Design

 

 

 

 

 

 

 

The product met the original proposal expectations.

1

1

2

2

2

1

1.67

The product met the terms of the proposal outlined in the team's project charter.

1

1

1

1

2

1

1.33

The design process successfully identified the essential element(s) for this performance support system.

1

1

2

2

2

1

1.67

The ePharm website follows a logical order.

1

2

1

1

1

1

1.17

The ePharm content is at a level appropriate for the end user.

1

1

1

1

2

1

1.17

The database management job aid follows a logical progression.

1

2

1

1

2

2

1.50

The database management job aid adequately addresses the need for which it was requested.

1

2

1

1

2

2

1.50

 

 

 

 

 

Category:

1.43

Development Process

 

 

 

 

 

 

 

Rapid prototyping was an effective process for developing this project.

1

2

2

1

2

1

1.50

The Open JAR team effectively utilized the rapid prototyping process.

1

2

3

1

3

2

2.00

I had adequate opportunity to provide feedback to the product during the development phase.

1

2

2

2

2

1

1.67

Changes to the product were implemented in a timely manner.

1

2

2

1

2

1

1.50

Product revisions appropriately reflect formative evaluation findings.

1

1

1

2

1

2

1.33

 

 

 

 

 

Category:

1.60

Project Management: Communication

 

 

 

 

 

 

 

Overall, communication with me was conducted in a timely manner.

1

2

2

2

2

1

1.67

Overall, communication with me contained the information I needed.

1

2

2

1

2

1

1.50

I believe my input to the project was given careful consideration.

2

2

1

1

1

1

1.33

From my perspective, the right type of communication (email, face to face meeting, phone) happened at the right time.

1

2

 

2

2

2

1.80

 

 

 

 

 

Category:

1.58

Project Management: Roles and Responsibilities

I was able to contribute my knowledge and skills to the development of the product.

3

2

1

1

2

2

1.83

I knew what was expected of me during the development process.

1

1

2

1

2

2

1.50

 

 

 

 

 

Category:

1.67

Project Management: Time Management

The project's intermediate deadlines were met.

1

2

2

1

3

2

1.83

The project's final deadline was met.

1

1

1

1

2

2

1.33

The timeline outlined in the project plan was appropriate for a project of this scope.

1

2

4

2

3

2

2.33

The timeline outlined in the project plan was realistic.

1

2

4

2

3

3

2.50

 

 

 

 

 

Category:

2.00

(Response scale: 1=Strongly Agree, 2=Agree, 3=Neutral, 4=Disagree, 5=Strongly Disagree)

 

 

 

Page Last Updated Sunday, April 27, 2008 10:13 PM