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


Storming through System Implementation

After the first functioning code delivery arrives in a system implementation, the client finds a mismatches from what they got and what they are looking for due to miscommunications & various assumptions. (As we have discussed in the Tuckman’s forming phase)

With so many differences between the delivery and the customer expectations, the team eventually figures out, they need a few large change requests to open up requirements & system’s capabilities. Thus, the project team will need to collaborate to derived process & functions that fit both the client’s needs & the system.

To succeed into the implementation, this step is an necessity to refine the system to fit the key business needs. Due to limitation of the interface/API, existing limits/functionalities of other systems or just plain regulations; it does take more effort by the team to define the appropriate changes.

Without carefully monitoring the type of changes being made, the scope can easily get out of control leading to project failure. Hence formal packages of change requests are needed to be signed-off to prevent scope creeps out of hand.

Similarities between Tuckman’s storming stage & the storming phase of system implementation. Tuckman’s team storming stage is define as follows:

“The team addresses issues such as what problems they are really supposed to solve … Team members open up to each other and confront each other’s ideas and perspectives … The storming stage is necessary to the growth of the team. It can be contentious, unpleasant and even painful to members of the team who are averse to conflict.”

If we equate the conflict in a team as changes in a system implementation, we will find many similarities a team development process and the implement projects’s lifecycle.

Tuckman’s storming phase
• Different people in a team with different perspectives & priorities.
• The team have various difference that leads to discussion & conflicts.
• The storming stage is necessary to the growth of the team. It can be contentious, unpleasant and even painful to members of the team who are averse to conflict.
• Without tolerance & collaboration the team will fail
Storming phase of implementation
• Different teams in the project with different perspective & priorities.
• The implementation have various differences in functionality & expectation that lead to require changes.
• This phase is necessary to refine the system to fit the key business needs. Changes will be needed due to limitation of the interface/API, existing limits/functionalities of other systems or just new regulations.
• Without understanding what are needed & what the system can be configured to do, the project & system will go out of scope and fail.

Just like the progression during this period, the planned expectations & actual results are similar between a growth in teams and projects. Most team growth, this part is underestimated or even missed by management during planning. Although output of the team relies on how well the conflict is managed & utilized. This is the same in system implementation projects, the project plan would complete correctness in the requirement & specification process, which underestimate this correction piece of the implementation piece of the project. Although the output of this piece is critical on how well the system will adapt to business needs & future processes.

By the end of this phase, deliverable/system has bugs & defect left … the overall system functionality would fit the client’s business needs. The project is near the original project deadline due to the unexpected difference & delays, although the progress of the system is similar to end of development phase in SDLC. There is still a long way to go, which is why most IT project doesn’t meet their deadline is because this phase of work is missed in early planning.

After 1st Systems Delivery … Just Doesn’t Fit

In the previous post, we reach our initial code delivery … the code & configuration worked, but there were gaps. It’s work & it’s close to what the client was looking for in the requirement … but as close as it can be, it just doesn’t with the external system, business process or results and missed some critical scenarios.

Even though the overall system work as clients needs it, there are some major functionality delivered that mismatch what the client had in mind. At this point, the client will realize the original requirement doesn’t fit some of the business scenario, the integration with the other system or what the business needs.

At this point either the project is restarted or requirement/specification redesigns are required for the various sections. In either case, a cycle of SDLC from requirement to validation of delivery is implemented in the form of a few large change request.

Requirement: Another joint application meeting is done to define the requirements & also define what is broken.

Specification: Defines specific conditions that was misaligned and apply the fundamental tweaks to systems functionality to fit what the client needs

Code Implementation: Revising the code while making functionality are not broken, also getting more clarification from clients.

Delivery Validation: Being more proficient, the client would quickly confirm the core changes are working to what business needs.

When the system just doesn’t fit business needs, some changes are needed. Although this phase of change is usually missed in project planning, because the project manager wouldn’t have account the requirements needs to be redone. Most would expect that period of code fix is needed, but not a redesign.

Since it needs a simplified instance of SDLC for system implementations, this means more work is needed and … pushes the project scope, cost & time to increase quite a bit.

Applying the Team Model with SDLC: The Forming Phase

Just like the Tuckman’s stages of team development, the relationship between the project, the product, the client & the vendor goes through a similar projects.

The first stage in the Tuckman’s model is the ‘forming’ phase. The 1st half of the IT project can be classified as the ‘forming’ phase. This is when the client defines the requirements & specification is developed & all items are formally signed off. All the requirements is developed between the vendor & client. Even though the client only have the slightest of clue what the system would look like.

The vendor tries the best to fit the requirement into a specification that fits the vendor’s product, meanwhile the client tries to refine the requirements to make sure it’s more less right. At this stage, there is just too many unknowns to have a clear picture what could be missing in the requirements.

Unbeknownst to both parties, both already have their own kind of miscommunication.

Many client would only know what they have been using, so most of the requirements would be driven by that. Which means they will tend to focus on issues & process that have been there … even though some processes are created due to a flaw in the previous system.

The vendor usually tries to understands the client requirement by what they think is what the client really wants, then tries to reinterpret it into the specification. Transforming ideas of process into list of specifications for developers to code sound less complicated than doing it … so that an easy task even for the best consultant.

A natural difficult task for many human beings is translating thoughts into words; Compound with this, it guarantees a mismatch in between the conception and the end-product.

Unfortunately this is unavoidable when dealing with so many unknowns & miscommunication.

As the result, many thing does seem to work right for the client when the code is first delivered. After a few weeks of fine tuning, the client will be able to test out the product … at this point the client will realize the code is missing some major functionality that is missed in the requirement, but critical to business.

After the first round of client testing, the project have passed the mid-point of their timeline; Since under the SDLC-waterfall model, they have arrived at the testing phase, which is one step away from acceptance.

This is where we will end the ‘forming’ phase … next up storming.

This is a general reason why SDLC might seem to work in theory, but never fully work in practice. That doesn’t mean we should not use the SDLC, it just mean that it will take more time to craft the systems using the various steps in the SDLC. Like the agile method, any software development project will require a few iteration of similar process to make sure the product is fine-tune to what the clients need.

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.

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.

Handling Missed Requirement

As the deliverable arrives, we were able finally to test it out after the long await. Unfortunately, we found out that a side functionality was only using at the address instead of both the account & address.

After talking to the consultant, we found out they were surprised that we were expecting to include the account key … It was a completely missed.

The miscommunication started from requirement definition due to the complexity of various scenarios. Although when the specification/design document arrived, all of the business & IT staff reviewed it & still missed the scenario … when we reviewed the document, we missed what was not in the design on the particular scenario.

Honestly in general, the code was correct expect for that missed item … so this missed requirement will be seperately managed by a change request.

As much we try to prevent it, miscommunication/misunderstanding/mistakes happen. We need to accept it, fix it & move forward.

Here are the process I followed this time to reduce any potential further delays:

1. Acknowledge the Problem (Don’t Blame):

Blaming is never good, acknowledge the issue & get to work.

If a process was miscommunicated or misunderstood, the issue will trickle down into the work that is being done. It could have been caused by client miscommunication, vendor misunderstandings OR both.

It doesn’t matter anymore, it happened … state what was missed & move forward.

2. Analyze the Impact:

Once we accepted that there is an issue to fix. Figure out the impact of the issue to determine urgency/priority of the issue.

This will also become your justification for the extra time it took for the fix. For my current issue, the impact would of cause a good set of end-customer not receiving a rebate/refund … due to the monetary impact to the bunch of future customers … this would be set as a priority issue.

3. Re-Determine the Specification/Conditions/Scenarios:

Write down the specifics of the gap/issue & what are the scenarios that needs to be covered. Don’t jump to look for a solution, you are blindsided by what you have seen.

For example, the issue we found was big enough, but after redefining the conditions.
We find we only need to update one of the key condition to include the account #, instead of just the address to solve the issue/gap

4. Collaborate on Solution:

Find an agreeable ground between the client & the vendor. This is to make sure no further misunderstanding occurs for this issue.

Oh, please write it down as well.

5. Document it:

This could be in the form of a change request or an agreement of change. Since change this is different from the original design, you better document it; otherwise when the project manager ask why extra time was used … you would be blame for misused a resource (even if you are right)

At this point, unless you want to hide the issue … just document it or setup a change request. Misunderstanding & Mistakes happen, just make the fix official (if needed, get it approved).

6. Let the Vendor Handle it:

At this point it should let to the vendor work on the deliverable, since the specification written down for the vendor.

Although makes sure you make it clear to the vendor that question & feedback are welcome … this way you will get what you need & confusion is minimized … also it will cut down on time to redevelop it again.