Artefact 5: Program Management

MDDE 605, as I have heard other MEd students say, was a challenging experience; it was the first time I had assignments returned, and financial forecasting and accounting are not my preferred activities. Despite that I am highlighting program management with its capital and operating costs, staffing models and resource plans, as an Artefact in my portfolio. The reason, as outlined in the Introduction, is that this Artefact connects theoretical learning to workplace demands, illustrating what I learned in MDDE 605 (as well as 617) to a real project involving new hire learners with real business and stakeholder demands and constraints. Also, program management, as an umbrella term for the end to end management of design and development of learning solutions, has an effect on the bottom line in any organization. More and more, our business stakeholders require us designers of instruction to measure and track any impact that change has had on the business and therefore demonstrate the value of learning.

Instead of showcasing assets from the course, Learning Assets 1, 2, and 3 were created during the solution design and development of a new hire learning portal in my organization (2.5). They reflect parts of the business planning process that I prefer: strategy, market and business analysis, and change management. The first two assets also relate to contextual design, a user-centered design process which represents something I felt was missing from MDDE605; our course assignments were built for reaching a go- no-go decision by those approving and paying for the solution but what of the voice of the user or learner? How should they factor into the design and development?

Learning Asset 1 involved collecting and consolidating data about users and what matters to them while Asset 2 physically represented 'the system' with which the user would interact with, and ultimately served as a blueprint for the design and development. I used both as inputs into understanding the problem or business opportunity facing our new hires (1.1 and 1.2), and as an output for communicating what we knew about our users to stakeholders and status (1.9 and 4.8).

In MDDE 605, we too had to do market analysis, gathering information about our potential market. I recall the assignments seemed to follow a very mechanical process akin to building a house with specs and blueprints, reviews, estimates and schedules. First came the business analysis, then the strategic analysis, followed by the detailed business plan, in that order. While I appreciated the rigor of the 'process', not every organization follows or refers to these exact steps in the same way. When I applied the process to the real world, customization was required regarding the 'communication' of the real solution in a format my stakeholders expected to be delivered, i.e. business analysis report would be a 'strategy' and business plan would be a 'statement of work'. (And as mentioned, the final plan was not written for the benefit or point of view of the users of the system.)

With the user journey (see Learning Asset 1), the new hire onboarding program represents a 'system' composed of software, hardware, services, support, and users. The paper prototype and wireframes (see Learning Asset 2) allowed us to iteratively test and refine our concepts with our learners and became a tool for communication with stakeholders as well to explain portal functionality (1.8, 1.9 and 4.8). The benefit of this design approach is that it is very 'participatory' where the users and stakeholders participate in the design of the system. The downside to this user-centered approach is that the inquiry can be time-consuming, or too brief yielding little data to work with. I had a lot of data sources to distill to provide an accurate picture of the issues we were needed to solve, such as completion rates of previous self-paced learning plans, satisfaction ratings from the orientation and participation rates in the communities (5.3 and 5.9) and having these details about our learner audience proved helpful to guide conversations and help stakeholders make decisions about development priorities (1.8, 1.9 , 4.3 and 6.3).

User focus testing was invaluable to guiding our solution but also to helping show business value and return on investment. Based on feedback from our pilot audience, changes were made to the user experience (i.e., changes to navigation to clarify expected actions) and gaps were identified in the learning content that was required for specific audiences (5.9 and 6.1). The positive reviews gave our stakeholders a sense that we were headed in the right direction and meeting our mission statement.

Finally, Learning Asset 3 refers to the change management process in program management. To bring awareness to our program, I designed an email campaign (3.5) bringing in the resources required to develop the communications deliverables (6.5) and consulted with technology team members to identify how to track participation (6.1 and 6.3). For all deliverables, I regularly collaborated and interfaced with dispersed project team members, stakeholders, and users to iteratively design and deploy the learning portal (3.5 and 4.8).

Competencies applied are indicated in parentheses.