Archive for the ‘Tips’ Category
Alternatives to Basecamp for more functionality
Tuesday, April 20th, 2010 by stephThe Six Thinking Hats
Friday, October 16th, 2009 by cindyedmondsSomeone tipped me off last year to a really useful technique. It may be one of those things that the rest of the world was aware of and I have been under a rock and missed it but in case there are some fellow rock-dwellers reading this blog I’m going to share the epiphany here. I’ve been working on a new business proposition over the past couple of weeks where it has been incredibly useful to apply this technique: Edward De Bono’s Six Thinking Hats.
The premise is that we all have a natural or preferred thinking style. For example, my thinking style is quite critical and ‘nit-picking’ whereas one of my colleagues is more optimistic and grandiose. When considering new business investments we need to apply both styles of thinking (and more) to the proposition to ensure we cover all bases. I’m sure everyone has worked with someone who you dread having a meeting with because they’re so negative or obstructive? I’m not saying I work with anyone like that right now but I have in the past and as a Project Manager it is imperative that I get the outcomes that I need from meetings and the Six Thinking Hats is a great enabler for this. (I have copied the following definitions from wikipedia)
- Neutrality (White) - considering purely what information is available, what are the facts?
- Feeling (Red) - instinctive gut reaction or statements of emotional feeling (but not any justification)
- Negative judgement (Black) - logic applied to identifying flaws or barriers, seeking mismatch
- Positive Judgement (Yellow) - logic applied to identifying benefits, seeking harmony
- Creative thinking (Green) - statements of provocation and investigation, seeing where a thought goes
- Process control (Blue) - thinking about thinking
Six Hats Thinking means that in meetings, for example, the team considers the issues while imaginatively or figuratively wearing each of the Six Hats in turn. Some people stay quiet during Green Hat as they can’t think that way and then jump in with enthusiasm during Black Hat. Genius!
Which Hat are you?
10 pointers for Agile Design
Thursday, April 2nd, 2009 by admin- User research is imperative but not ad infinitum - set limits
- Interation with development should be informal but large scale changes need to be managed via the iterative planning session (e.g. Sprint Planning etc)
- Use artefacts to communicate with clients and the team
- Use paper prototypes to find out what works for users
- Too many designers spoil the user experience
- Documentation should be based on what is required at that particular moment
- Don’t invest tons of time in mock up early on as it may have to be undone later
- Track design somehow but be aware that using similar techniques to engineering tracking can lead to issues as design often comes together late in the day resulting in a mammouth burn on the last day - meanwhile the project manager is already pulling his/her hair out. Understand the differences between engineering and design tasks
- Don’t be afraid to show the customer stuff early - just set the expectations and ensure that they don’t cling to designs before these are solidified.
- Have courage, be transparent and remember that everyone is headed toward the same objective of a successful project
What makes a good project office?
Thursday, February 19th, 2009 by adminThe main point to remember is that a project office has one goal and one goal only: make everyone else’s lives easier so that they can deliver stuff. The goal isn’t “create loads of documentation so that when the project goes wrong no-one can blame you or your project manager”. If your project goes wrong baby, you know which way the sewer flows and you’d better have more than just a hefty PID to back up your argument when it does.
The fact remains that if you spend your time chasing people for reports which they have no time to write, maybe you should ask whether you can get the information another way. However, don’t set up an hour long meeting when you probably only need a 20 minute telephone conversation. A project manager’s time is precious and reporting (although important) is not as important as delivering.
Secondly, once you’ve elicited the information then give it back to the person who gave it to you. If you are asking for that information then somebody else is probably asking them for it too. At the very least they might need it themselves and they will no doubt thank you for putting order around chaos.
Finally, (but by no means least), if a project manager gives you some information about their project, then store it somewhere safe. Make sure its accessible next time you need to update your records because one thing’s for sure; if they told you it once, they don’t expect to have to tell you again any time soon!
For information about Project Office opportunities with Magic Milestones email chris@magicmilestones.biz
[polldaddy poll=1385112]
Why SIPOC is good!
Thursday, May 1st, 2008 by adminIf you go to http://www.isixsigma.com/library/content/c010429a.asp you’ll find a “how to” on SIPOC. SIPOC stands for: Suppliers, Inputs, Process, Outputs and Customers. Its a good way of defining a process and then working out where the holes are. We did this today and the results were very structured. Basically, the method is as follows:
If you have a project that is ill-defined…
1. Get the relevant stakeholders in the room and work out 5 top level key processes that describe the scope of what you are trying to do. For instance selling a car would be: Attract Customer, Establish Need, Provide Options, Negotiate Deal, Hand Over Keys etc etc.
2. Next, for each part of the process try to document the outputs
3. Then document the customers
4. Next it should be easier to do the suppliers and the inputs.
Whilst you are doing all of this, note down any issues that come up in conversations, for instance, there is an issue trying to work out whether the customer wants a low emission car or not…
Once you’ve done all of this, what you basically have is a top level ideal process, a list of issues with the as-is process and finally, take each issue and try to assign an action to it.
In the end you should be able to construct an action plan for defining the project in more detail.
You should now:
- Have a better idea of scope
- Know the problem you are trying to fix
- Be able to establish some quick wins
- Be able to establish ownership of actions
TIP: Try to stay focused on the issues rather than the solution. Otherwise, you may “solve” a problem by the end of the workshop without fully appreciating what the problem really was!
Thanks to Jackie Jones of BT Expedite for teaching me this technique 
Recent Comments