As the last semester came to a close, I too decided to perform the painful but rewarding activity that I’ve asked my students to do many times before: document a reflection of what I learned through mentoring projects. The more challenging part that I took on, is that I also wanted to make the reflection public. I’m balancing candour with diplomacy in mind. I think it valuable to talk about my own perceptions of the client, learner and project without learner or client feeling like my reflection is aimed directly at them. This is a reflection that is more interested in keeping the picture big and revealing some of the inherent challenges of industry facing projects in our curriculum. Some of the lessons learned from my POV are not simply ones that emerged from this semester, but over the last few years. They are in fact recurring themes. These insights may provide you with some of the changing weather conditions should you ever want to guide/mentor/advise/design real-world projects in an academic learning environment. Other lessons may be specific to the environment that I teach in. I’ll leave the generalizability of my observations to the reader.
Meanwhile, I will continue to discuss, stream and record a variety of subjects related to education and the professional educator with Jon Festinger via periscope #pjed Friday mornings.
Firstly, this is not my first reflection. In fact the number of reflections are revealed in the drawing above. Why?
- I mentored a total of 8 projects; Three at the MDM Program and five on a more part time basis at the Sauder School of Business @ UBC.
- If I hadn’t blasted out words previously I would have lost most of those moments that come and go so quickly, that I don’t have the capacity to retain.
So really, this is a reflection on all my reflections. A sum up of the summary. A usefully redundant exercise that I can make public without all the adjectives sometimes present in the earlier reflections. Here are some of the things that I’ve learned.
- Every single project has its own process and no one rule can rule them all. I say this because the smarties that make a project run (including clients and learners) all bring something to the table that, based on the personalities involved, will not flow, function and result the same way twice. This is important to recognize because it makes researching project-based learning a slippery rocky road filled with generalizations and assertions that are only as good as the learning environment they have come from, and the relationships that have influenced those assertions.
- Every single one of the students I mentored this year worked hard (most of the time). Most clients realize this, but not all do. Why? I think, in part because learners and I have to get better at communicating all that we do more persistently and why we undertake certain activities in the design process. We can’t always assume that a client is going to understand what it takes to ‘throw’ together a business plan, to program the ability to change velocity in a Unity based virtual car ride, or the user stories that come out of a hell of a lot of research into product development, UI, UX, psycho-demographic profiles, empirical research, colour theory, blah blah blah. We (me too) have to become better at communicating with each other what we do, and why. Yet another reason to SCRUM daily. While I scrummed some days with my teams, I didn’t do so persistently and more than just once a week with all teams might benefit all of us.
- We as a team of learners and faculty cannot change the way that someone operates their business. We are not there to challenge their value proposition, or to question whether or not they even have one. We may, however, as was the case with a few projects, influence that value proposition and provoke our clients to rethink and refine their own by seeing the delivery of a new product/baby that may one day become part of their critical path. At times learners think that clients come in the door wanting us to fix their business model, but it’s just not the case. Unless it’s part of the project deliverables, then it’s better to focus energy in delivering an artifact that may one day inspire a completely new business model.
- Sometimes a client coming into a project with vague pre-conceived notions of what they are going to get is inevitable. As a team setting out to solve a design problem we (me, client, learner) need to be more comfortable with ambiguity. We also need to be okay with making tangible what the client later decides they don’t like. The flexibility and negotiation as to what the team comes up with in terms of deliverables also depends on how willing clients are going to trust teams quickly. That trust is always earned by solid impressions (showing interest, passion, organization, and following through), particularly in the early stages of ideation. Blow the trust at first for whatever reason and you spend a lot of time having to re-earn it. Understanding this tenuous relationship between earning trust and clients being more open to how you can improve upon their idea and offer better solutions is important. Managing expectations and delivering something they hadn’t even thought of, that solves their problem….is always a nice surprise.
- We all need to sit down at the first meeting and really understand that we have the same meaning for many terms, like the term ‘critical path’, for example. Most clients in educational environments are told that teams cannot tackle a problem or fulfill a need that is on their critical path and they are ok with this. But…..what does that even mean? I can guarantee you that many projects that came out of projects that I’ve mentored, magically transported themselves onto a client’s critical path, simply by nature of how good the deliverables became. That’s not a bad thing. But teams in educational environments need the freedom to stray from the path, to experiment, to fail..productively. Every team needs to understand what critical path means to their client and what it means to team. Clients also may need to affirm that they are not dependent on what the team builds in order to launch a product or pitch an idea, etc… However, clients also have a right to hope that what teams build has that potential. And should the potential for something as tangible as a working prototype manifest, then by all means let’s critical path it. Let’s hand off something that is scalable, that deserves to be further developed.
- Clients and learners need to understand that there is no real centre of teaching and learning in project-based learning environments. Faculty, learners, clients, resources, other members of the cohort, books, research, parents, friends, all figure into that giant equation of whom am I learning from exactly. Clients, you are now officially co-mentoring. We’re not asking you to. It’s just going to happen as soon as you provide feedback on anything the learners are doing. The only difference between you and I, is that I submit their grade at the end, while you consider them as potential future hires or individuals that you’d recommend to your circle. That said, clients too have to understand that we have all agreed to produce work in a learning environment, not a work environment. We are not trying to emulate a working environment. We are trying to learn from creating a product that solves a problem or fulfills a need that a client has asked. What we are learning is also not always a shared phenomenon but at least we are all learning to fulfill a need or solve a design problem. Like our learners, like me, clients will also have a better time if they too are open to learning new things about the product, the perception of their business, and how they interact with learners.
- One client is the best client. Not two or three that disagree. One aligned voice of reason to ensure that there are no mixed messages. The gods of old will come down and bless you all for this. Learners will end up being more productive. It’s a simple equation: The more clarity, the more unified the message and therefore the more a team will deliver. The less miscommunication and misinterpretation, the more likely that a team of learners will remain aligned throughout a project and deliver gold.
- Although friendly and amicable, the client is not your best friend. You just met them. More importantly, however, the client is not your enemy either. Sometimes a needless us VS them arises from some client-team relationships. I’m curious how that develops. It’s by no means with all the teams but on occasion it does happen. Maybe, it’s because clients have also taken it upon themselves to be mentors to learners and there’s a resistance from learners to accept that. Maybe it’s because clients believe they know more than learners and yet they have come to them with a problem that they want learners to solve. A contradiction. Not really. It’s hard though to let any team develop an idea that you have and not try and control its direction. On the other hand learners can become easily dismissive of client opinion and guidance, if those opinions burst the bubble of an idea or direction the team of learners become attached to prior to aligning with their client. While there’s never the same reason behind why a client relationship doesn’t always feel right, there are some solutions. One that I’ve seen work seems to be to include the client more regularly (weekly or more) in design decisions to remain aligned with ideas, with vision, with what the final deliverable will look like and why certain choices were made that have informed the design. The other seems to always come down to answer and communicate the why. Why did we as a team decide on a particular decision? While a client has a right to agree or disagree with the reasoning, at least they realize that some time and thought was put into the decision itself.
By sharing reflections on the project-based learning process in this way, it is my intention to inspire further conversation into the sometimes tricky territory encountered when academic programs take on real- world client-driven projects. I’ll post other reflections after another cycle.