Failure to Plan is Planning to Fail
Posted by appWise Content Manager | Tags: Project Management
When developing an application, many things are considered. âWhat do we intend to do?â or âWhy would a customer or user consider us over the competition?â are usually the questions asked in a new venture. Usually the stakeholder provides all these answers. However, more times than not, the outcome of the best planned project can fall short. The reasons vary but in many cases it can be attributed to one person providing the scope or mission statement for the project or having the technical aspects of the project drafted first and the reasons for doing the project considered last.
Over the past few years, I have been working on projects where owners, sales teams developers and content providers have all worked together to produce the scope of a project before the storyboards are drawn, before infrastructure is purchased and code is committed to the repository. So how can you get a group of competing egos to work together, you may ask. Simple. Affinity diagrams.
Ok. Before you fall asleep consider this, especially if you are a project manager. Allowing a diverse group to participate in the development process will avoid the inevitable engineering blind spot (weâll talk about that later). Because the idea that one person holds the tome of knowledge for any problem is asking for failure. So here is Affinity diagramming in a nutshell:
1. Get a big dry erase board with dry erase pens.
2. Get some felt pens to write notes
3. Get a stack or two of Post-It Notestm
4. Gather about 4-6 people that have a vested interest in the project make sure their jobs are diverse (it WILL help)
5. Plan the meeting for 1 to 3 hours.
6. Produce a statement of the problem. E.g. We have been operating the client portal for our brick and mortar clients for over 6 years, but few customers use it.
7. Produce a question, from group discussing that addresses the problem. Usually a Why or What question. E.g.âWhat is keeping the customers from using our customer portal?â And write the question for everyone to see.
Now you are ready to move on to the fun.
8. Have each member write about 10 relevant, supporting statements (void judgments, blame and caustic statements)
9. Stick the statements to the board.
10. Each team member reviews the statements and offers input that eliminates bias and reforms the statement. E.g. âAll our customers are old.â Becomes âCustomers lack technical knowledge.â And so on.
11. Everyone commits to being silent.
12. The team begins to group the statements which reflect similar ideas rather than by attributes associated with the companyâs business.
13. Similar statements are stacked. Some may not produce a grouping. Lone Wolf statements are OK.
14. Any team member can take a note and move it to another group at anytime ? IN SILENCE.
15. Once a member is confident the structure is satisfactory, he or she takes a seat.
Whew! Lots of work so far. Make it fun. Provide a snack if it keeps the groupâs interest. Now we are getting near the end.
16. Get another color sticky mote pad and write a header for each group. This should summarize the facts in each group.
17. Stack all the facts under the headers.
18. Rearrange the headers into groups of similar attributes, circle the groups and write a group header. Since our example is a web portal these might be: Inconsistent Language or Term Confusion, Request Timeouts and Errors, data Relevance and Freshness, etc.
19. Number the headers from most to least important in the groups. Do this by group voting.
20. Draw lines of relationship between groups if appropriate.
21. Create a final statement that summarizes all the headers and facts. Write it under the statement in step 7
When the group is satisfied that the project is completed they may give a group signal such as a chant, or clapping to indicate the effort is done to satisfaction.
And there you have it.
There are no comments yet...Kick things off by filling out the form below.
Leave a Comment