Simon@iSchool

Well, the academic year 2008-2009 has ended, just like that. It may seem odd that there were no updates here near the end, but there’s an explanation for each course I took this semester…

Human-Centered Computing (CS 260)

This course was mostly reading and discussion in-class. Interesting readings, provided on the course website. I was involved with presenting two of the topics: Activity Theory and Ethnomethodology. The final project in this class was a precursor to my Master’s thesis, about creating a collaborative game on mobile phones for unschooled children in rural India. You can compare the two versions of the document as they were prepared for different audiences:

• Final Paper and Presentation
• Master’s Thesis

Effective Project Management (INFO 290-11)

The work I did in this course was mostly involved with an organization on campus known as RSSP-IT. My work for them involved confidential information about their customers (students living in the dormitories) as well as insider knowledge about their internal systems that could be used to compromise them, so I felt that it was best that I didn’t share the details.

Essentially, my work for them was to aid in adoption and planning for a centralized account management system for employees and residents alike.

Interface Aesthetics (INFO 290-6)

Unfortunately, due to the overwhelming load of my research project and the other coursework I had this semester, I was unable to commit to completing assignments for this course and decided to drop it from my schedule this semester. My work up until that point is still something I’m proud of, and I did learn a lot of neat things and insights that I wouldn’t have otherwise. I use these new insights to critique and analyze interfaces and visual displays around me all the time now.

One of the factors of my deciding not to continue in the course was my novice-level skill with Photoshop/Illustrator/similar tools. It took me about three times as long to do something as most of the others in the course, and I knew I couldn’t dedicate the necessary time to surmount the learning curve. Perhaps in the future, I will try again.

So that wraps things up for this semester… And because I have now fulfilled my requirements for the Masters degree in Computer Science, this wraps up things forever! I am leaving the iSchool, a wonderful place with some of the sharpest people I’ve ever met.

Congratulations to those iSchool students who graduate as Masters this year as well! And good luck to the rest of you in your year(s) to come.

Follow me on sybak.com from now on.

–Simon Tan
Ambassador of Computer Science for the School of Information

The Pareto principle is the idea that, in general for many events, ~80% of the effects come from ~20% of the causes. For example, it was observed by Vilfredo Pareto that 80% of the land in Italy was owned by 20% of the families in his time. In business, the Pareto principle is used as a rule-of-thumb: 80% of sales come from 20% of clients, 80% of customer complaints originate from 20% of products/services, 80% of production capability comes from 20% of staff, etc.

The key concept is that there are ‘vital’ elements (20% of something that has an 80% -huge- impact) and ‘trivial’ elements (the remaining 80%, which due to symmetry cause merely 20% of the effects). The main take-away, then, is to invest limited resources in the vital elements and not the trivial ones.

When applied to project management, quite a few phenomena can be explained: 80% of the value in a meeting will come from 20% of its time, 80% of managerial problems/stress come from 20% of employees, and 80% of the time and resources spent on a project will be from 20% of the stated work. If we then focus our limited resources on the vital 20% of each situation, we should see a greater return on our investment and reduce the amount of wasted resources (i.e. the resources spent on trivial, low-return activities).

Taking the example of meetings further: If you can identify the vital 20% of your meeting that will provide 80% of the meeting’s value (and/or take 80% of the meeting’s time), you should put that part of the meeting FIRST in the agenda. Focus on the part of the meeting that is truly important, and ensure that you obtain the 80% of value from it instead of having your meeting cut short due to lack of time.

This write-up was based on the following research:
* management.about.com/cs/generalmanagement/a/Pareto081202.htm
* www.envisionsoftware.com/articles/Pareto_Principle.html
* en.wikipedia.org/wiki/Pareto_principle

A work breakdown structure (or WBS) identifies all of the tasks required to finish a project, usually in a hierarchical structure. It is basically a glorified TODO list, but it is one of the most powerful tools a project manager has. This is because a WBS helps to provide a detailed illustration of the project’s scope, can be used to monitor progress, aids in creating accurate cost and schedule estimates, and builds project teams in that that it gives team members a sense of how his/her work fits into the overall effort.

The WBS is built from the top down. The project is broken up into the various deliverables, which are in turn broken down into the particular tasks needed to produce those deliverables. Only the lowest-level tasks are called “work packages” – anything in the chart that contains subordinate tasks is called a “summary task“. Summary tasks are never actually executed – they become complete through the progress of their work packages. Each work package (lowest-level task) should follow these rules of thumb:

• The 8/80 rule – No task should be smaller than 8 labor hours or larger than 80.
• The reporting period rule – No task should take longer than the distance between two status points (i.e. if you have status meetings every week, no task should last longer than one week).
• The “if it’s useful rule” – Only break a task down further if it makes the task easier to estimate, easier to assign, or easier to track. If it won’t do any of these, don’t break it down further.

Here are the major steps needed to build a WBS:

1. Begin at the top – List the major deliverables or high-level tasks from the scope statement.
2. Name all the tasks required to produce those deliverables – Turn the deliverables into tasks by adding a strong verb in front of them (e.g. “Shrubs” -> “Plant the Shrubs”) and then break them down into lower-level tasks.  This is harder than most people think. If there is trouble doing this, it is a sign that a small meeting of top-tier people is needed to help break it down. It might also be a good idea to give a task to an expert in the subject and have him/her break it down for you. Even if this process takes a long time, it is worth it in the long run. Projects often run into “blind alleys” if a clear WBS is not made early on.
3. Organize the WBS – It is possible to rearrange the work packages in different formations, which could emphasize different aspects of the project. Move the tasks around and group them under different summary tasks until the WBS is meaningful to the people involved.

Three more guidelines:

• The WBS must be broken down from the top. It is crucial to ensure than work packages are subsets of their summary tasks.
• Work packages must add up to the summary task. Don’t omit tasks; it becomes much harder to estimate costs and time if the WBS is not complete.
• Each summary task and work package must result in a concrete product. Don’t be vague or unclear. “Do research” is weak and is open-ended. “List candidate vendors” is more concrete.

There are quite a few documents that a project manager should write up (or at least consider) in order to get his/her project off to a strong start.

• Project Charter – An announcement that a new project has begun. This could take the form of a memo, a letter, or an e-mail. The charter contains the name and purpose of the project, the project manager’s name, and a statement of support (typically from the sponsor, who really should sign this document). The charter is sent to as wide an audience as practical; it establishes the project and the project manager’s right to make decisions and lead the project.
• Statement of Work – This contains the goals, constraints, and success criteria for the project. It includes a purpose statement (why are we doing this project?), scope statement (boundaries), deliverables (both intermediate and final), cost and schedule estimates, objectives (criteria for success), the list of stakeholders, and a chain of command (organization structure). Many of these components are expanded upon in later documents (e.g. a requirements document), so the statement of work should defer to those documents as necessary. This is more of an overview of the project at a glance.
• Responsibility Matrix – A table that details the responsibilities of each group (of stakeholders) involved in a project. It lists the major activities of the project (tasks) crossed with groups/people (e.g. HR director, VP of operations, etc.). In each cell, fill in these tags: “E” = responsible for execution, “A” = final approval authority, “C” = must be consulted, and “I” = must be informed. This lets everyone know at a glance who should receive what amount of information and work.
• Communication Plan – A table that describes (1) who needs information? and (2) what information do they need? It may also detail how often status reports will be made, escalation procedures, how often information dissemination happens, the schedule of regular meetings, etc.

Other tips from class:

Who do you invite to your kick-off meetings? Not everyone. It’s impossible to get all your stakeholders in a room – consider having multiple kick-off meetings with different subgroups instead.

Right as the project begins, start two lists right away:

1. Project issues – a list of the problems that come up and how they are resolved
2. Lessons Learned / Best Practices – things that you’d like to improve on next time

Keep updating them throughout the project.

As I go through material for my project management course, I can’t help but notice that a lot of concepts are delivered in sets of “five things”.

Here are some sets of five that I’ve pulled from The Fast Forward MBA in Project Management and a reading from Making Things Happen. They should provide an easy-to-use reference for better project management skills.

The five factors essential to the success of a project

1. Agreement among the project team, customer, and management on the goals of the project
2. A plan that shows an overall path and clear responsibilities and will be used to measure progress during the project
3. Constant, effective communication among everyone involved in the project
4. A controlled scope
5. Management support

#5 is obtained with a signed charter, #1/4/5 are bolstered by a detailed statement of work, responsibility matrix, and communication plan.

Some reasons projects fail

1. Incomplete specifications
2. Insufficient labor
3. Unstable funding
4. Lack of sponsorship
5. An impossible business case

Five rules for effective meetings

1. Pass out an agenda in advance (at least one full working day)
2. Begin and end on time
3. Ensure each agenda topic has one of these three goals: to pass on information, to come to a decision, or to gather information
4. Draw people out; don’t assume silence is consent
5. Record decisions and action assignments and check the action list for completion at the next meeting

Five ways to annoy someone with project management activities

1. Assume they are an idiot (over-define their work)
2. Don’t trust them (require lots of check-ins)
3. Waste their time (send ambiguous messages and force tedious tasks)
4. Manage them without respect (don’t look out for them)
5. Make them listen to or read stupid things (force content that has no bearing on the work they are doing)

The effects of good processes (not bad bureaucracy)

1. They accelerate progress
2. They prevent problems
3. They make important actions visible and measurable
4. They include a process for changing or eliminating the process
5. The people impacted by them are in favor of them

Five pointers for better meeting facilitation

1. Establish a host position
2. Listen and reflect on what people say
3. Direct the conversation with the agenda and manage the floor so everyone is involved
4. Know when to end the conversation if an issue should be resolved elsewhere
5. Make history with documentation and recordings