Rss Feed
Tweeter button
Facebook button
Linkedin button
Delicious button
Digg button
Stumbleupon button

Posts tagged application support

Taking ownership of tasks – when should you or when should you not?

Its often expected by customers that the vendors take ownership and full accountability of the projects and related pitfalls. While on one hand its good to take ownership of the tasks in your project and deliver them on time, within budget and exceed expectations, its equally important to understand the remits and scope of your work and project before assuming the responsibility & the accountability of failures.

Not only by the customers, but the display of the ownership from team is demanded by project managers & senior managers as well.

A Dilbert strip below just about sums up how the management assumes project teams to “own” things !

dilbert_ownership

Quite rite ? Do you think so ?

It is essential, to demonstrate the capability to own and deliver the things, however it is equally important to know the limits of the ownership and a clear understanding of what you should deliver and be accountable for. 

If you are into application support and maintenance projects, its even more important to know your project boundaries & scope so you could actually define the components you own and maintain.

Typically in the support projects, with the scenario of multiple support teams supporting various components in an end to end journey, the problem or fault can lie in any one or more components in the chain.

If any service impacting incident occurs in such scenario, I have seen customers pushing the front end (or Portal or Website) support teams for solutions and RCAs. Irrespective of where the problem or issue lies. It is fact that in a web based journey the problems are only visible in browser and thus generally it is perceived that the teams that supports the actual portal application are responsible for owning the investigation & resolution of issues.

Generally it is OK for the ASGs to take up the responsibility of owning the issues & try to get a solution in place ASAP. However, it is probably too much to expect them to own the end to end stack and push for investigation & resolution where the fix lies outside the boundary of the support team.  In such cases, I would rather have the E2E Service Managers to own the fault and drive the resolutions through the downstream systems rather than the poor portal ASG teams. 

I do not think there is any concrete definition or rule which says which tasks / issues / problems / escalations you should own up and which you should not. However, in case of the conflict I would suggest it is always better to stick to the rulebook (i.e., scope of work, application boundary) and take a wise decision.

After all, you would not want to lose brownie points !!

Adopting Enterprise 2.0 for managing my project teams based across continents

Continuing from my earlier post on using ‘twitter’ for better collaboration within IT project teams and taking it one step further, I have been contemplating on actually adopting an Enterprise 2.0 software stack for real time collaboration, better communication, effective knowledge management & idea generation amongst my team.

The obvious problem at my hands is lack of budget to actually look for and adopt any proprietary software that would solve our purpose, thus a little more intelligence & effort is needed to ensure we have a good set of working processes, software & tool to enable us become an effective project team.

Being into production support and providing critical support to few prime portals of one of world’s leading telecommunications company, the need of time is for the team to have an effective collaborative tool at their hands which would allow them to exchange short messages via web based intranet portal.

So to cater to this requirement, we decided to install Laconi.ca and try that out. Hopefully we will have something to work on by end of this week.

By the way, after my earlier post, few of my team members came back to me disputing my claim of unawareness of ‘twitter’ within them. So it was good to know as well !

Another important bit was to have a knowledge management portal and for that we installed Mediawiki solution on the LAMP server I had on the Intranet. Obviously it worked as a treat so far and hopefully it would continue to serve as a KMS solution for us.

But the problem we are having is about carrying out the backup of the Mediawiki. Obviously one simple way is to back up the database tables & then back up the file system separately. However, I was just wondering if there are any ready tools available that would execute the backups on the Mediawiki installation and give me an installation kit to restore, if eventually we need !

Few things I have installed on the server are Open Office (OpenGoo) to manage the documents online for the team. However, so far never used it for a real project purpose though. I would like to see how I could use it in my project in future though.

I have also had an installation of b2evolution lying on my server which I intended to use for the team blog for spreading the news on updates and progress on various changes / issues, but as of now it looks a long shot for the team to actually start using it. Obviously it would support the RSS / Atom feeds as well. So I would have to hold on for a while.

As a part of my objective of increasing the collaboration within the team, I have created something called Ideas wall and Questions basket that would give the team an opportunity to interact with the management & post ideas for new innovations, opportunities as well as ask questions on the processes around the project.  Just for the sake of mentioning, these two are plain wiki pages in a team section for me and that worked well so far.

So far I have not felt a need of having a Social networking intranet portal for the team as the size of the team is not really big and although we have resources spread across various locations in the world, its easy to connect with each other with the existing tools. So may be I can keep that idea in reserve as of now.

As usual, if you have any comments or any ideas for me to take a look, I would welcome them. So please leave a comment on my blog or ‘twit’ me on Twitter.

Using ‘twitter’ for better collaboration within IT project teams ..

Today, during one of my team review meetings, one of my colleagues raised an idea of having a chat server hosted on intranet to allow the team members collaborate with each other for issuing and requesting updates on various incidents, problems and their progresses. A good idea to have one chat server, but few team members were probably not pro to the idea due to the ‘push’ nature of the chat and they did not want to be disturbed with many messages broadcasted to the team if they were not of any interest to them.

Then the obvious solution to this idea was to install ‘twitter’ like microblogging software on one of my intranet server and allow teams to follow rest of the team to ‘pull’ the updates as and when they need it.

To my surprise, when I explained the concept of microblogging to the team and gave an example of ‘twitter’ to the team, none of my team members seem to know ‘twitter’. This was a shock to me, especially when my team was supposed to be pro in Information Technology !!

Nevertheless, explained them the concept of microblogging to the team and asked them to explore ‘twitter’ concepts and find out how it works.

laconica Upon doing the search myself, I found Laconi.ca best suited to our needs of having an online microblogging and collaboration tool for the team.

I would still need to get the team explore this product and get a pilot installation tested on our intranet Linux server but by the looks of the product, it looks to be exactly what I needed for my team to enable better collaboration.

Anyways, few main expectations I am having from this kind of collaboration tool being used in the support project is to enable the disparately located team put up updates on a simple question @What are you doing?@.  Obviously my team is located at various locations across India & UK so having a centralized tool would certainly help us in better collaboration.

Another important usage I envisage of this tool is to give updates to customers about any major release updates or change implementation. It is obvious that while the teams are busy doing the installation of a software on the production servers, they would not like customers or any other teams asking the questions on status updates and disturb them.  So if we have this kind of tool, it would definitely enable us ‘post’ proactive updates on intranet which could be followed by various customers / teams to find out the updates themselves.

Thus, a job for me tomorrow is to find out someone in my team who could take on the job of doing the R&D and install the Laconi.ca software on my intranet server and take it from there ..

Customer care – Dilbert way !

Today’s Dilbert comic strip is really awesome and how apt it is for people who work in support & maintenance projects to try this in their work !!

Lol !!

 

Dilbert.com

Adopting technology for automating business usual work in support .. still reluctance?

So frustrating … ? Isn’t it ?

I do not know why in the world I see people doing the same and same jobs such as health check of system, carrying out scheduled maintenance & housekeeping jobs and not thinking of automation.  I find that kind of stuff really boring, frustrating and irritating if someone asks me to do so even twice! 

I have seen lot of people who never say a word and will keep on doing the same and same job again and again and never complaining about that. They do not even question the value of the work and efforts they are putting in. Especially in the support and maintenance projects I have seen plenty of examples of tasks that are done month on month without anyone looking to review and take a look at how to automate them? The typical tasks such as health check monitoring, scheduled maintenance & housekeeping jobs, proactive monitoring of processes & instances etc, is done each day / week by spending hours on the task.  Stunning fact isn’t it ?

When I think deep into the reason of why people do not like to think laterally and review what they are doing and what value addition they are doing to the project, I find few common patterns which could very well be managed and nurtured to change for the good of the resources and eventually the project.

Few of them I could write as follows,

  1. Resources do not know what they are doing – Most of the times I have observed that the routine work is delegated to a new trainee and they do not really take efforts to understand WHAT they are doing and WHY they are doing.  They only know HOW things should be done.
  2. Self motivation  – While most of the times the routine tasks are carried out by newcomer or a trainee person in the project, I have also observed that these guys are not given enough knowledge sharing to get them a start in the project. They are just given tasks and asked to learn from that. Only telling HOW of a job, does not give sufficient information to the resources & hence they lack self motivation to question themselves on the job.
  3. Hierarchy in the organization – You can not really question your senior manager if you are given a task of doing a routing work, can you? Especially when you are a team member of a support team. In my opinion, one should be brave enough to ask questions and especially justify the value of a person putting hours of efforts for silly work that could very well be automated. But simply the fear of asking your senior, sometimes kills that motive.
  4. Traditional tasks .. this is how it was always done – One of the most common reason when I ask people why can not they improve on the current situation and look for automation in their area. The knowledge that is passed over from a team leader to a team member is observed as often limited to HOW a job done rather than WHAT is it and WHY you are doing. That further means that they are just meant to do what they are told and not deviate from anything else!  Thus, when I asked one of team member of a vendor support team about providing some information on incident investigation, the answer I got back was very typical .. “I do not know much because I did what was always done and was told to me! Its a traditional way of doing it.” 

People in many offshore support teams simply turn up for the job and do it, without getting into the soul of the job and using common sense to automate and in effect introducing efficiencies in the project.

Sometimes its so frustrating … ? Isn’t it ?