When delivery happens

Last was a pleasant week, why? the delivery happened.

After one week of bug and fixing we deployed the application and the time response was very good in general.

The customer had a lot of concerns with this point and the percentage of functionality we covered is going up.

On other services there were some bad behaviour due to a network problem. It affected to some end users so there were some impact on the business. Just 3 hours of outage but the 18 affected users were recognized and informed. At the end, the application owner was happy with the way the situation was handled.

I was able to recognize some business needs, what is quite good, lately there are not so much real needs bout for this we can go ahead with it.

:-)

Vendor complaints process

I’m looking for an standard process for the management of the vendor complaints.

I have found some documents in the internet, the more interesting one is this, that has helped me to understand what could be the scope of the process.

But, is there somebody who know if there is a standard guide or best practices to manage the vendor complaints specifically?

Thanks in advance

Accepting that this is a "change"

We are finishing the build phase of a project, starting the test phase of the project and know the client has noticed that there is the need to add a functionality.

We have need one week to let them recognize that this is a change request due to the requirement was out of scope. The formal process has been launched today but I would like to review the emotional process that the client has covered.

First, they was annoyed because the functionality was not there: what’s happen? why the application does not do this?

Second, they have saying, hey just take note of other bug and add to the bug tracking list, so that afternoon they seem to be comfortable.

Third, in the revision meeting we classified this bug as “improvement” and told to them. Again they were upset.

Four, they were reviewing the project plan and the gaps of this in order to suggest how to adapt this plan to add the functionality without affecting the plan. No way, the plan was explained, and that was not the solution.

Fifth, the project manager of the client (that belongs to the IT department of the client) and the main contact of the final client (other department) complaint each other: the first says “there’s no more budget you have to use the application without this functionality…”, the answer is simple “…we are not going to pay nothing and accept any application that does not cover the mentioned functionality”. In summary: stress, displeased…

Sixth, the project manager of the client escalates the situation internally in their department. The action is to request formally an estimation of the required functionality.

All this process has been handled by the analyst that is assisting the test phase, the project manager and myself that have been working very hard the communications (so many hours on phone, in meetings and in the corridor… making the message smoother).

Let’s see how it works, there’s still a lot of things to do.

Funny situation, the queen of ambiguity

This is the excellent e-mail I have received today about a problem of a project:

——————————————–
Hello,

we’ve a big problem with the project XXXX.

In module YYY the basis functionality isn’t covered. The users need the possibility to filter on every field. As John (joapen: John belong to my team no to customer’s team) explained that was part of the query tool (what was cancelled in project definition because of the costs) . For us it was not visible that even this basis functionality was cancelled.

The ZZZ department cannot use the module without this filtering function. We need a solution to solve this issue. As an interim solution we discussed with John to insert the Excel export button in every YYY screen. But we are not sure if this will run fast enough in practice.

Best regards
—————————————————————

Reread the following sentence,

“For us it was not visible that even this basis functionality was cancelled.”

That’s a very good phrase after being 2 months working on a functional analysis specification and a detailed design document. I can remember the person involved in this process investing a lot of hours detailing all activities in detail, with a lot of revisions on site with the client.

And now, during the test phase, we are the ones who are not delivered this functionality.

I love this funny situations, we already have started the change management process.

Destroy the 10% of your job

The idea I want to mention today is not something new. You can read tons of literature about it.

The stuff is related to the continuous changes we live in our jobs.

There’s a rule that google made popular that was the 80/20 rule, where you let 20% of an employee free to let him/her to do what s/he wants: time to think, time to invent, time to improve…. time to change.

The idea with this rule is that the consequence should be that at least the 10% of your current position should change and then really the added value of this person in this position really keeps constant. The part of this 10% of activities/responsibilities depends on a lot of factors.

What happens to this 10% of activities you lose? They could disappear because they are not necessary anymore, they can be moved to other places where this is an activity that provides value, you can be a work generator so now there is another person helping you to do this fantastic job…. there’s a lot of alternatives but the fact is that you cannot do the same thing for years, I mean: months.

There is a lot of fear to the change: “this is my job”, “what should I do then?”…. It’s something like when the babies repeats “this is mine!”.

I need to review where is our added value with the team and keep clear the reality of the competitive world where we live. The good thing is we have time to react.

There will be a time where I will be caught by this phenomenon, I will be out of the market.

Assessing my portfolio

Identifying the applications needs of the portfolio, I’m basically facing these situations:

  • You have to reassess the current conditions of an application and decide if to enhance it or remove it.
  • You decide to retire an application in order to minimize the cost.
  • You need to renew an application for keeping it flexible or to perform functional needs.
  • You have an application (probably key) that you need to redevelop to minimize risks, improve structural capabilities or increase functional capabilities.
For all these assessments, what I basically do is to ask myself different questions:

  • Is the application easy to use? easy to learn?
  • Does it well with the way work is done?
  • Does it cover all the needed functionality?
  • Does it help us to be productive and efficient?
  • Can be easily adapted by the user to meet evolving requirements?
  • Are the technical conditions the right ones?
  • Is the application support cheap/expensive?

It requires a lot of knowledge in terms of the customer and end user vision.

I work a lot on this point of view in order to do not fail in the “IT geek” perspective.