Showing posts with label Operations Research - Project Management. Show all posts
Showing posts with label Operations Research - Project Management. Show all posts

Sunday, August 1, 2010

Want to be creative? Don't brainstorm.

I'm sure many of us have had the thought before, "Oh, I wish I were more creative". I have. I'm also sure many, many of us have led or participated in a brainstorming session before. I also have. Apparently, these are both counter productive to being more creative, according to this article. To top it off, apparently since 1958 it has been proven that brainstorming doesn't work. I never knew about this. Did you?



In businesses, one of the common outcomes of operational research work is improving a particular process. We often start with understanding the problem, to mapping the process, and to building a model that reflects the current process. Eventually, to add value to the bottom-line, the model hopefully reveals some insights, and is the tool to test out certain ideas to support any process changes. Personally, it is often a pleasure to be involved from the beginning of problem understanding to the end, managing the recommended process changes, because as an OR consultant, you get to see your work to fruition.

Of course, to succeed in change management, the ideas should come from the stakeholders who live and breathe the process in question, and eventually own the solutions to be implemented. To get ideas from stakeholders for process improvement, the common technique is to gather stakeholders in a room and brainstorm on possible solutions.

Given the information presented in the article, to prepare for the brainstorming session, I take away that we should consider to:
  • present the problem to the group before the brainstorming session,
  • ask them to prepare and think about possible solutions that their colleagues or friends wouldn't have thought of for resolving the issues,
  • get them back in a room to discuss each other's ideas and prioritise on the ones to investigate feasibility and impact,
  • but before they start discussions, get them do some aerobics for 30 minutes if they are somewhat fit (half serious, but wouldn't that be fun?),
  • culture them with a youtube video about the weird and cool stuff in other countries (half serious, but wouldn't that lighten up the mood?),
  • facilitate the session with careful language to not instruct people to be creative
  • facilitate the session so the group moves back and forth between a couple topics to be able to take a break from focussing on just one solution
  • and perhaps not name it a brainstorming session, because it may be the forum that people associate with "get creative...now", which is counter productive, as per the article
Read it if you've got 3 minutes. Let me know what you take away from it that I've missed. (See the instant application?) The main points in the article to help someone to be more creative are:
  • Don't tell them to be creative
  • Get moving
  • Take a break
  • Reduce screen time
  • Explore other cultures
  • Follow a passion
  • Ditch the suggestion box

Monday, February 1, 2010

Healthcare system improvement project management: making a big team work

It's tough chairing meetings, tougher chairing a big meeting (10-15 people), and tougher yet chairing a big meeting that's supposed to last an 8-hour day, one day a week for 6 months. A lot of planning goes into making such a day work with team members varying from the analytical kind to the "feeling" kind, from the surgical kind to the managerial kind. I'm slowly to get a hang of it having done it for a couple months now. The following is a lot of common sense, but if one doesn't have the chance to go through this kind of work with big teams, one may not think it so obvious as an approach. Thought I'd share for whatever it's worth.

  • Make sure everyone is doing something - feeling of usefulness in the group, or else people will feel disengaged.


  • Assuming natural progress of project is from problem discovery, to analysis, to design and implement, and assuming that everyone in a team needs to participate in all phases, then keep telling self that as soon as we get through to design, things will become more exciting. Analysis phase is not everyone's cup of tea, even though geeks like me find it most interesting.


  • Spend the time and create a big poster out of rolling parchment paper. It becomes a live document of all work done on the project to remind team in every meeting of key aims and work accomplished so far. It is a pat on the shoulder for work well done, as well as always showing the direction for the team. Sometimes, one can't see the forest for the trees.


  • Big team, big scope - recipe for getting lost or losing sight easily; remind team of aims frequently; relate how current tasks contribute to the aims.


  • Identify one lead for each main task to be done in the implementation phase. Give team members enough time to develop own plans on how to implement, and write the document themselves to instill ownership from the start (do not use admin resources to do this). Sometimes it takes 2-3 days just to write and re-write the implementation plans, but the time is worth while, not because we need to have a perfect plan as that is unrealistic, but because it forces people to think of all nitty gritties of how get things done and how they would get around specific change management problems. Provide a good example from a colleague of theirs (real examples from real people = trust), but encourage and give them room to be creative. Then everyone on the team should peer review each other's plan with specific review criteria.


  • Once you have all of the above done, engagement level should be pretty high by now, as a healthy amount of sweat and tears will have gone into the implementation plans. I bet anything that you won't be able to hold people back on actioning out those implementation plans.

There you have a much happier and motivated team. There is no sure recipe. This isn't one by any means, but it is working for me so far.

Friday, November 6, 2009

Healthcare system improvement project management: how not to manage projects


Lately, I am finding it difficult to not do the work myself in the projects I'm leading/managing. The excuse I've been using is "well, it's just easier to do it myself than asking someone else for it". However, I end up paying for it with way too many late nights working around the clock. I'll be the first to admit: this is the wrong way to manage projects. I end up feeling burned out and tired doing work that should have been done by others in the team, leaving me without enough energy or time to actually 'manage' the projects. Ultimately, if I continued this way, it would be both bad for me and the projects.


However, I used to lead projects like this before, and it worked charmingly. What changed?

Well...

Here I talked about the Master of Management in Operations Research program that trained me as an OR professional (great program by the way). During this master's program, each student is a project lead on a 4-6 months project with a real company doing real projects. The students are fully capable of carrying out all tasks within the project, but have data analysts to help out, because there is just too much analysis work for one person usually. A project lead in this scenario is both the leader and largely the doer - what I'm used to do at work both before and after the master's program.

Why isn't it working now? In my humble opinion, leading 2 projects with relatively large project teams is quite a busy job. One simply doesn't have the time to both lead and do. I did, so I paid for it. Then I learn. I guess in this case, it would probably be overall easier to ask someone else to do it than doing it myself.

Got any tips to share with me? Comment here or email me at dawen [at] thinkor [dot] org

Sunday, October 25, 2009

Healthcare system improvement project management: what's the right balance?

I now live in London, UK, and work for a rather famous hospital, renowned for its medical reputation internationally. My role is a project manager on 2 system improvement projects. Such projects are also labeled as "transformation" or "modernisation" projects, depending on where you work. The idea is to work with doctors, nurses, managers, clerical and administrative staff, as well as patient families, who live and breathe the hospital, so that this group of people take ownership of the problems and solutions. We meet one day a week for a full day, and project managers like me and lean improvement facilitators are thrown into the mix to try to help the projects move along. The key is all about implementation, which may make some external management consultants jealous, since they almost never get to implementation. It is a luxury as one can see one's work flourish.

Great idea, isn't it?

Is the team too big?
  • 20% of 8-12 people's time is huge! On paper, the staff are 'back filled' for that 20% of work, but in reality, finding the right people with the right skill mix to do 1 day's work is quite difficult. Therefore, these people often end up working 120%. Commitment to the team starts high but then lacks off a bit.
  • With the amount of time invested, people outside the group have very high expectations. They want to see things getting churned out from the team quickly, and often ask "when are you going to deliver what". When in reality, such projects have a research nature to them. There may be the best of project plans, but research will always take as long as it does until you can move onto solutions.
  • Keeping 8-12 people 'entertained' and interested in the same topic is challenging. Some people are very detailed. Some want to talk big concepts. Some just want to start getting into the issues and start tearing it apart. Keeping everybody happy is never easy.
  • Big groups also suffer from democracy. It takes time for everybody to have their say, and one person can dominate the whole discussion and shut others up. The good facilitators will still find this difficult.
But is the team too big? I've definitely experienced the same group, but with fewer people, and we were very productive for the small group days. True, everybody in the team should be there because of their functions within the hospital, but perhaps they don't need to all be there every week.

Ideas on how to tackle the big group:
  • We are now trying to break the team into smaller groups to be efficient, and to break the group dynamic. Each sub group also has a sub lead, so more people can feel true ownership within the team. We then reconvene after half a day to update each other on progress. It seems to be working so far.
  • Send team members out to the hospital to observe, collect information, shadow someone else, and then update. It breaks the 'classroom' feeling when in a meeting room.
  • Of course there are many facilitative ways to deal with it as well when they are all doing this: :)

I find these projects are shaping like way more people talking than actually doing the work. It is especially frustrating for the ones who actually joined up for doing the work. I've definitely done successful projects in the past that didn't involve such an elaborate set up. This way of working should make implementation easier. I am waiting and seeing.