Archive for the ‘ Productivity ’ 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)

Observed from Implementations: SDLC Iterations & Tuckman

From the Tata Consultancy survey (2007):
    “62% of organizations experienced IT projects that failure to meet their schedules”

From the Robbins-Gioia Survey (2001):
    “51% viewed their ERP implementation as unsuccessful”

With complexity of large IT/ERP systems implementation, various misunderstanding & miscommunications are unavoidable … This disrupts the SDLC model by making each phase to be revisited at many points of the project. This usually generate unaccounted delays to the project, which could cause the result you see in quotes above.

After going through several module implementation, I have seen a pattern. After the 1st code delivery … there is almost a guarantee a massive change request or redesign document. After that is done, the regular defect appears for fixes.

The traditional waterfall model and most major project planning expects people get the solution right in one shot. But of course this never really happens, it takes several tries developing & refining to get to an acceptable solution. That’s why many all IT project ends up different from the original requirement.

From observation, it seems it naturally goes into a few core iteration of code implementation before the solution is ready to go-live.

After studying project management & learning about Tuckman’s stages of team development. I notice that developing an IT solution from start to go-live ready is similar to a team going from forming to working productively. Although each iteration seems to go through a simplified version of SDLC. (Feasibility, Analysis, Design, Implementation, Testing)

Forming Phase:
This is where the client defines the requirements & specification is developed & signed off. This phase end when the first code delivery for the requirement is tested.

Storming Phase:
When this occurs, the client finds there is a mismatch between what they imagine and what is delivered. This part involves the redesign/massive change request to get the solution functioning per the client’s business needs.

Norming Phase:
This is when both the vendor & the client understand what the client needs, both are polishing the system/solution to a stable state.

Performing Phase
This part can only be archive when the solution is actually performing, through post go-live period.

In all of these phases, QA & programmers are needed for on going development & validation before the solution is usable for the client.

Unless you a building a off-shelf solution with zero customization, project planning would go off track. Instead of viewing a IT implementation as one long SDLC, plan better by anticipating mismatch in spec & refinement in deliverable.

Next few posts, we will go in depth of the phases.

Stay Motivated, Move Forward

I have been in the current ERP project for the last 2 years, while some of the people in the team have been in the project for almost 4 years. With all the obstacles & delays, staying motivating about the work is not the easiest task.

That’s why I’m not surprise at WorkAwesome’s post about the #1 way of staying motivated. They said the #1 way of staying motivated is Making Progress (at 76%); While Collaboration is second with 53%. It had been a bit frustrating during the summer months when we were not seeing any major progress.

Project seems to be very similar to riding in a ship to cross the sea … it keeps rocking back & forth; When deliverables arrives, it seems like it was 1 step forward & 2 steps back, where a new fix breaks something else. This really demotivate the team, since we get were excited able the deliverable the day before after a long wait.

Here are some ways we tried to maintain team motivation:

Keep Track of the Changes & the Why
Since the project is slowing down, the first you need to do is to determine the cause. It could be due to the vendor process, our internal process, a just person in the team (internal or external member) or just some expected obstacle. No matter what it is, you or the project coordinator need to determine the cause & figure out if it’s under your control or not. If it is then do whatever you need to move it forward.

Follow-up
Always follow-up, to make sure you not waiting for nothing

Write on the Wall
Have some kind list of completion in the project. It will show everyone that progress is being made. This does remind everyone that we are moving forward, which does seem affect other positively.

Focusing on the Low Urgency Important Work
When things seems slow, create or review the list of important tasks. A lot of times some of those item gets lost, so it would be a good time to go back & close some of the issue. It’s unfortunate, but most of the time at work: urgency > importance (unfortunate) … since urgency drive stress, while importance doesn’t always.

Finding Little Victories
After identifying the important task, create some smaller goals to push forward of the important pieces of the project. This will move the project forward & the team can claim these as smaller victories. For example, we preparation work & detailing step for future testing of the implementations; even though it might not seem urgency, it will become important when to time tightens when the deliverable arrives.

As long as we push forward we are making process, that means we will be motivated to push forward … it’s an momentum thing.

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.

Good Days, Bad Days and Productivity

This week I personally had 2 good days & a bad day. I noticed the difference in results I was able to deliver between it.

Productivity really gets impacted on a bad day, while it feels like you can do anything on a good day.

On the 2 good days, I was able juggle a dozen tasks at once. Then navigate & troubleshoot issues left and right. Then coordinate some fixes, while guiding a intern through the project.

On the bad day, I just couldn’t connect my words & sentences with my thoughts. I was stuck in a 1.5hr status meeting, then I keep on making mistakes on testing for a fix for 30 minutes …

Eventually, it balanced out between the few day to become a better than average week.


Some bosses expect a constant stream of productivity out of their employees every second; Unless we are robots in a factory, I don’t think that’s realistic. Everyone have good & bad days, but in the end it’s the overall results that matters.

This is as true in IT as in anywhere else. On a good day, programmer’s mind was able to ski around the codes; While on the bad ones, they would keep on hitting red lights when trying to fix a bug with a mysterious error message.

If you are having an really unproductive day, don’t stay behind for that day … You are not doing any favors to anyone, because it might take you working in an unproductive hour on something that can be done in 10-15 minutes. In such an scenario, just cut you losses for the day & be better prepare for tomorrow with some … zzz …

That’s my 2 cents