Project Governance: Avoiding “Administrivia”

1. Project Governance:Avoiding “Administrivia” Lisa Kosanovich Project Manager Center for Instructional Design Brigham Young University lisa_k@byu.edu

2. Copyright Information Copyright Lisa Kosanovich 2005. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

3. Brain Development

4. “Administrivia”- reactive approach to problems that arise • “Who is the Boss?” • Design problems are being resolved in a vacuum • Complete project status and issues do not reside with one person or in a collective whole • Project Plans need “revamping” on a regular basis to clarify when the project will finish and what ‘really’ remains to be done, few know when their work should be done

5. Project Governance- proactive approach to projects • TEAM: Define Team Roles and their functions • SCOPE: Change Management and a Scope Steward • COMMUNICATION: Communication Framework • SCHEDULE: Scheduling Tools and Principles

6. Managing by project governance

7. Team • No one is the “boss” • Everyone has a key role to contribute throughout the life of the project • Example: • Designer: steward of the scope for the project, technical design and resolution • Sponsor: Define what is needed, make decisions on behalf of the user • Production Staff: Provide technical solutions, build product • Project Manager: steward over project information

8. Scope Change** Matrix *Consultation with the ‘steward of the scope’ will clarify what size a requested change is. **Changes should be based on a constraint matrix

9. Scope Constraint/Flexibility Matrix Directs change decisions that are made, in an attempt to protect that which is most constrained

10. Communication • Team listserv, alias, or group email • Weekly Team Email • Meetings: • Brainstorming • Consensus gathering • Changes that need negotiation • Issues that will require more than one conversation within the team • Almost NEVER for status

11. Schedule • Define tasks at the level where issues occur and status is most meaningful • Do not plan past your next point of knowledge • Use the best tool for the job • Waterfall vs. iterative • Task driven vs. date driven • Checklist vs. Schedule

12. Date Driven: Biweekly meetings during design phase of a project Schedule is most constrained therefore dates will be drawn out by which to achieve certain features Decisions need to be made even though research or work may not yet be complete Task Driven: Scope is most constrained therefore work will continue until all features are achieved Many resources or outside vendors are involved, requiring coordination of deliverables Many dependencies exist within the project requiring coordination for timely completion Schedule

13. Schedule Checklist

14. Brain Development Today

15. Managing by project governance

18. Questions? Lisa Kosanovich Brigham Young University lisa_k@byu.edu