Archive for the ‘ Priorities ’ Category

Norming to Go-live

The next stage of Tuckman’s team development is the Norming phase. Team Norming happens where the team have one goal to a mutual plan & all the team members takes on responsibility to aim for team success on the goal.

At this point, the implementation project is close to being late from the original schedule … everyone now is aiming to for the implementation to go-live.

After going through 1-2 major redesign changes from project storming (previous post), the functionality should be close enough with actual business need that no functionality change would be allowed by the project manager & leads. All of the testing & development is done is to polish the system and getting rid of any bugs without changing functionality.

This point, it is to bring the implementation to a close and any changes will be consider in a separate individual change request or a project for collection of all the change in a service pack to better align the system with the business process.

In case of any functionality doesn’t fully fit the business process, documented processed will be needed to utilize the system with the least impact with the business process.

For the system implementation, just like the forming phase, the project team & the business units starts to take responsibility of the implementation & learn how the system will integrate with the business process. Since everyone start to notice the implementation is becoming a reality & how it halts other new project from starting … they all have a common goal & they are more willing to compromise to push for the system to go into production .

Once the system goes into production, it will slowly reach the performing stage.
(which I will talk about as I go through this process in the next few weeks)

Requests Losing in Priorities

As I dig through my old e-mail & to-do last friday, I stayed behind again to close out some of the pending task that got lost in priorities for the week.

Half the time, I find that other priority is overwritten by other priority, I also found this is true for most of the people I work with. With each e-mail, each meeting & each day passes by … more & more tasks goes on our queue.

Here’s the Problem: A ‘Medium’ priority can easily becomes ‘Low’ after a few new requests.

In IT, we rely on completed task of others to close or even to start other of our own task. In basic development process, Development is need before Testing & that is dependant on Design. To prevent from bottleneck, we need to be organized & follow-up.

Incoming Tasks: Organizing & To Do
Using some Get It Done techniques, here are some task that has been helpful for me

Write It Down:
Rather than remember tasking, I write down a list to handle the tasks to be done with the next 1-2 days

2 Minute Rule:
If there are a task/e-mail that can be done in 2-minutes, then do it immediately. I usually set it 5 minutes instead of 2 to be more effective.

Long Term To Do:
For the tasks to follow-up on & meetings to-do, use a digital to-do list (google task) to track & follow-up

Outgoing Tasks: Follow-up
Nowadays, everyone has dependency task where someone have to finish a task or 2 before you can start on your task.
To make sure your request don’t get lost in priorities, here are 3 simple thing you can do:

1. Don’t Assume
Don’t assume a task would get done … we all are busy on some/most days, we can miss some task if we are not organized.
So don’t assume, just follow-up.

2. Follow-Up
Use a light toned follow-up by asking for an update in a short e-mail (you can also offer to help or any clarification)
… don’t follow-up too much, it would just get annoying & they would help you next time.

3. Be Understanding
Everyone (including you) have missed a request once or twice due to other priorities. So if someone missed it after a day or two, just ask for updates, don’t guilting them for missing it. (Guilting them won’t help, but ruining relationships)

Many company has their own task management systems but don’t just rely on it … create your own system. It took me a lot of trial & error to find something that I can used as some kind of task organization

By end of that day, it felt great to close some of those task that could of been a bottleneck if left not done.

Don’t Define Specs During Brainstorming

The table next to me at the cafe sits 2 developers planning to develop a software for a restaurant POS system. They are currently designing specification by think of what store would need & what user would do.

This is definitely not the first time I have overheard someone defining specification like that … Heck, I have done similar meeting with a friend of mine to figure out some kind of application. While overhearing, I was thinking … where is the user? Why assume when you can ask?

With specification decided the developer without the user:

• The user might already have a efficient/easy solution. (non-issue for the user)
• End-user will not use it, if your systems is not much more easier to learn & use …
• Solving the wrong problem, it creates more work & new problems for users to fix
• Unsatisfied customer, since the system doesn’t do what they need
• …
Remember the users have to deal with it at the end, so go ask the user/client

As a recovering-developer, I know the seductiveness of look for solution first. If you don’t have a defined list of the problem, you are going cause a different set of problems that the customer has to deal with at the end.

By defining the specification first, you are:

• Making uninformed decisions that causes the end users numerous problems
• Unnecessarily limiting possible functionality & design
• Making bad assumption about the resources & users
• Mistaken with what the real problem the customers are having

The point is: By setting specs first, you are making decisions/requirements for the client/user.

Sorry for going on the soapbox, maybe because I spent a year planning with a friend for a web business that didn’t go anywhere. Also I seen too many failing startup site that seems to design by imagining the user rather than asking user’s feedback.

Honestly, I don’t know the detail & I wish them success.

Getting over Bottlenecks: Perspectives & Priorities

When was the last time you got stuck at work/project, because it’s dependent on others’ part? That’s a bottleneck & it happens to many of us on a daily, if not hourly basis. It even get more frustrating when you find out no work has been done it while you are waiting so you can complete your part.

In IT projects many task rely on each other but I do find that some tasks get dropped until it’s too late & impact the project. To make sure important tasks doesn’t get stuck at a bottleneck, you will need to convince other the importance of the task in their perspective.

Everyone & each role has their own priorities. In order to get someone’s attention, you got to know what’s important to them.

Here are some role specific priorities:

  • Project Manager: On-Time
  • Developer: Making it work as per spec
  • Business/System Analyst: Make sure things doesn’t break
  • Database Admin: System performance & data integrity
  • IT/Project Coordinator: Clear Communication/minimize confusion

(Of course, these are not their only concerns; but it’s important to their role)

In the last post, I mention why project manager will concern about time > money in most scenarios. To get the project manager’s attention, you can focus on how your bottleneck would impact the project time, rather than just requesting to get it done.

Why would we need to do this, isn’t this part of their job?

Nowadays, most of us has a million things to do; as the day goes on, your request can get delay because:
– We/They don’t have enough time
– Other priority overrides
– We/They are juggling too many balls
… or any other reasons
In short, sometimes tasks does get dropped … that’s the reality. That’s why you sometimes need to explain from their point of view, so they will give it priority.

Like requesting for anything, the approach is as important as the ask; It will end up with a difference in results.