ECE493 Version: 24 Aug 2010

1. MANAGING YOUR CAPSTONE DESIGN PROJECT ECE493 Version: 24 Aug 2010 Prof . Michael F. Young myoung22@gmu.edu

2. The Capstone Project is a Group Effort • All members are expected to act professionally • Personality differences among members are not relevant. The common goal is all that matters • Respect each other by: • Doing your tasks on time • Keep in contact with each other (attend weekly meetings, etc) • Helping other members without being asked • Keep yourself organized • Work through frustrations • Focus on your assigned task and get the job done • Plan ahead • Planning will help you to run a project faster and ‘safer’ • Think what can go wrong and always have a ‘Plan B’

3. Managing Your Project • Roles and responsibilities of the: • Project Manager • Technical Manager • Financial Manager • Team Members • Task List: What it is, why it’s needed, how to create it, how to use it to keep the project on track • Financial Issues: How to manage the money spent • Time Tracking: Keeping track of time spent each member spends on the project Warning: One person should not take on all these management roles. They must be shared.

4. Managers • Each team must have someone in each of these positions • Managers are not “bosses”, however team members must cooperate with them in order for the manager to do his/her job and the project to be successful • Mangers are also team members and will have the same responsibilities as other team members Job Tip: Employers take notice if you can say in a job interview and or on your resume that you were a Manager on your senior Capstone project.

5. Project Manager • Acts as the team Point of Contact (PoC) to the FA, CC and AC • Creates and updates the Task List or WBS • Responsible for the timely delivery of reports/doc • Makes sure the trains run on time, i.e., monitor project progress and ensure assigned tasks are done on schedule • Call meetings and keep the minutes • Resolves problems, esp. among team members • Keep the team motivated, focused and working together • Real PM Job Description

6. Technical Manager • Responsible for all technical aspects of the project • Assists in the creation of the product/device requirements/specifications • Overseas the engineering and software task from a technical standpoint • Helps team members when they get stuck on a problem • Plans and supervises the integration of the project • Creates the Test Plan • Supervises testing

7. Financial Manager • Responsible for all financial aspects of the project • Approves all expenditures before the are made • Keeps all receipts from members for all expenditures • Keeps an detailed Excel spreadsheet for all monies spent • Collects money from all members and sees that they are properly distributed to each member so that each pays an equal amount by the end of the project • For projects sponsored through GMU, one person should make all purchases ­ due to GMU reimbursement process

8. Financial Guidance • Each team must decide and agree upon on a budget and how it will be funded • Typically, all team members are expected to contribute equally - unless someone volunteers to pay more • Some teams spend as little as $200, others as much as $600 or more • All purchases must be pre-approved by the Financial Manager • The final disposition of the hardware for the project should be discussed in advance. E.g., a team member, sponsor, or FA may want to take possession of the device at the end of the project. Or you may want to donate it to the school or just throw it in the trash Jump to Sample Financial Sheet

9. Team Members • Complete the assigned tasks by the due date • i.e., keep your word: do what you say you are going to do • Work professionally with other team members • Attend all meetings • Respond promptly to all emails and phone messages • Record all your project notes in a stitched (not spiral) notebook. Bring it to every meeting • Keep track of the time you spend on the project • A good place to keep this is in your notebook • Report the time weekly to your PM

10. Team Members (con’t) • Be familiar with all aspects designs • Share your knowledge and experience with other team members • At team meeting, share what you did and how you did it • Work smart, not hard Warning: Peer review will be confidential. If a team member does not pull his/her own weight, it will show up in the individual Team Evaluations!

11. Work Breakdown Structure (WBS) • A tree structure which shows a subdivision of effort required to achieve an objective • Developed by starting with the end objective and successively subdividing it into manageable components • Provides a common framework for the natural development of the overall planning and for dividing work into definable increments from which the statement of work can be developed and technical, schedule, cost, and labor hour reporting can be established. • A work breakdown structure permits summing of subordinate costs for tasks, materials, etc., into their successively higher level “parent” tasks, materials, etc.

12. Sample WBS’s

13. Perhaps too complicated for most Capstone Projects

14. Simple Task List • The key to a successful project is: Plan your work, then work your plan! • All the important tasks must be identified and put in the plan/list • While a complicated WBS is not a bad idea, not sure that it is necessary • You can use a simple Excelspreadsheet or better yet: Microsoft Project. • MS Project has a learning curve, but a valuable tool to know how to use Job Tip: If you can say on a job interview and resume that you are quite familiar with MS Project, you will be ahead of other candidates

15. Task Criterion • Tasks should be grouped according to functional areas (e.g., mechanical, hardware, software, documentation, testing, etc.) like in a WBS • All the important tasks must be identified and put in the plan/list • If a task takes more then, say, 20 – 40 mins, or cannot be done at one sitting, then it needs to be on the list • A task must have an end point. Unless you can answer: “What constitutes completion of this task?” then you cannot list it as a task. E.g.: • “Research <blah blah>” is not a task since the research could go on forever • However, something like: “Research <blah blah> and make final recommendation on what we should use” is a good task

16. Task Detail • Each task must have a least the following information • Task Description • Start Date • Planned Completion Date • Person Responsible (only one person) • Team Member(s) Assisting • Status See Sample Excel Sheet Task List • If you use MS Project, it will also show a duration in calendar days

17. Tips for your Task List • Give the file an intelligent name with a date; • e.g. "FX RX 16 Aug 10.mpp” • Put realistic dates for completion. Make sure the assignee agrees to those dates and "owns" the date and the task • Make it easy for a reader to know when a project is completed • e.g. highlighted in green when done or red if its past due. • Remember the purpose of this list is to identify what needs to be done so the project can stay on schedule, not to waste time with trivial, unnecessary work on the list • e.g., If a new sub-task that pops up that is not on the list after it gets done, forget about it. • But if there were a BIG job or problem, took a lot of time and you want to record it, then you can add it after the fact.

18. Tips for your Task List (con’t) • There should be no headings called: Miscellaneous. Be specific. • Put all the major headings that you think you may need even if there are only a few (or no) specific tasks under these headings yet. For example, you will need a headings for things like: • System Integration • Testing • Documentation • User Documentation • Product Specification • Final Report Preparation • …other areas you figure it out for your project

23. Team Meetings • PM should: • Create an agenda before the meeting • Schedule the meeting at the same time each week is the best • Confirm that all the members will attend • Take attendance and keep minutes • Stick to the agenda, don't wander • New topics not related to project management should be tabled until the end of the meeting • Allocate time for mini-design reviews so members can share their knowledge • Formal part of the meeting: < 30 minutes

24. Keeping Track of Time • Each team member will be required to keep track of time spent on the project • The totals must be presented in the final ECE493 report and during your public presentation • Suggest that you record your time each day you work on your project in you project notebook • The PM should gather the team from each team member at their weekly meeting that they can assign a dollar value for their work • Consider keeping track of two type of efforts: • Time spent educating yourself • “Productive Time” spent on specific project tasks

25. Keeping Track of Time • It is suggested hat the time spent educating yourself on a particular technology that you know nothing about should be reported as Educational Efforts, not Productive Time e.g., If you know nothing about say, power MOSFETs, SMPS, wireless data comm, etc.; the time you spend on your own to get familiar with them should not be “billed”. But once your start applying that knowledge to your project, then the “clock” starts • Time spent in meeting is considered as productive time (even if no progress was made) . See sample Time Sheet

26. Q & A Period • Any questions or comments? • Any topics you wish to discuss in more detail?