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


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.

Project Management as a Soft Skill?

From my last post on IT Soft Skills, someone asked:
 Why list project management as part of soft skills?

Like all soft skills, project management can’t just be learnt on an manual. It must be nurtured through experience to gain the skill sets.

The goal of project management is to balance between scope, time & cost.
In layman’s terms, project management is to complete a specified result on the time you set before the money runs out.

To do this, an project manager will need to:

• Communicate effectively
• Organize & coordinate activities
• Track & the progress of the plan & financials
• Negotiate with other about resource
• Analyze & manage risk
• Prioritization
• Lead & manage the team

Most of these would be classified as communication, interpersonal or leadership skills … all of which are classic soft skills.

Essentially a project manager needs a good set of soft skills for accomplish a successful project. That’s why even though the project manager don’t physically work on the project, they play a critical role in projects (Especially in IT).

It a good reminder that project management derived from a set of soft skill and the importance of gainings such skill.

The Vital Pillar of Project Management

Anyone learn a bit about project management knows the three PM pillars/constraints are Scope, cost & time. All 3 needs focus to have any kind of project success, but there are priorities.

What is a PM’s most concerning constraint between Scope, Cost & Time?
     Most people will say $$$
That’s what I thought too … until I took my strategic project management class.
     In fact the key constraint is TIME.

Which would you choice?:

An experience developer that takes 5 weeks for $15000
An decent developer that that takes 8 weeks for $10000

Rationally, it might seem the latter would be the right choice (the other cost 50% more).
But if you consider the project becomes delayed for 2-3 weeks, It will cost for the project way more when you have to pay everyone for 2-3 more weeks. That’s why, a week or 2 of delays in time could push the budget overboard.

Time isn’t just about time, it directly affects cost too.
   So in most cases, a project manager should prioritize “on Time” > “on Budget”.