Freelancers for e-Service: How far how good?

We've heard about freelancers. We've heard people talking about it. We've read about them time and again in newspapers, internet and other media. Who ARE they?? To analyse wheather freelancers would be cheaper alternative to big time IT companies, we need to know them. How they work, what process they follow, how flexible are they etc.

The so called process in every IT companies for letting any project in is very complex and thats a truth. I mean complex compared to that of freelancers. The client first gives out the tender to which a quotation is sent in response by the company followed by lot of formal business meetings with the so called Business Analysts where they talk various points like total number of head counts required, details about the existing system, technical, s/w requirement specifications etc. Then, the client has to send the purchase orders to the company. Finally... then the work has begun !!!

The same procedures has to take place if the client is approching freelancers. But then, the problem arises when we think of co-ordination.

The reason why...

The main reason why I scrap up my blogs with a lot of variety topics is that I need to get a confirmation about the whatever I learn by just scribbling, just as we did in the school days. So here instead of scribbling it down on some piece of paper which may vanish away anytime, I just type away something that I recently learnt. It brings about such a sweet feeling, you are making online notes on a specific topic, creating online contents for a audience and various other varsities that exists today in the web world.

Most of my posts are more likely to be in some kind of dogmatic or say... instruction mode... But then the readers here should realize that I'm just a student making notes. Its rightly said by someone "If you can explain what you have learnt, then I say, you have learnt in the real sense". The fact is undeniable that the proces of making such notes by the way of explaining someone makes your knowledge level not only pervasive but also serves as a great positive purpose for the people in the neighbourhood who are more likely to be interested in the topic looking for some solutions, ideas or a second opinion.

I've always believed in writing it down...no matter how least we may feel the importance of it. I remember the words of the Principal of my high school.."...a faint ink is always better than a sharp memory". So here I am. Please contribute and post your comments for a better perspective.

Back to Application Packaging.

I'd expressed about "MSI packaging" in the post dated back 14th of June 2007 on what I think about the same. I'm back with a bit more understanding. I thought of putting all those in words here.

In my simple sense, it helps you to get an application installed in target machine as I mentioned earlier too. Usually when we say "package", we tend to think something beyond technical frontline. Simply pu up, a package is a collection of files and directories in a defined format. You could say its a application software... delivered in units or an archive or store of files and directories required for the software product or something. This work as per my perception begins after the entire application code is ready. A s/w product is required to be built into one or more packages so that it can be easily transferred to a distribution medium; for eg: AD's Group Policy (I think so but not very sure). Once distributed s/w product can be mass produced and can be installed by administrators.

In its 1st Step, we need to Create pkginfo file. This file is an ASCII file that describes the features of the package and the information which controls the flow of installation. Each entry in the pkginfo file is a line that establishes the value of a parameter in the following form:

PARAM= "value"

Some of the mandatory parameters are: ARCH, VERSION, PKG, CATEGORY and NAME.

ARCH (Specifies Package Architecture) is a set of alphanumeric tokens which indicates the architecture associated with the package. pkgmk produces an installable package to be used as input to the 'pkgadd' command. The package contents are in the directory structure format.


VERSION (Specifies Package Version) parameter in the pkginfo file identifies the version of the package.


PKG (Package Abrreviation) is just the short name or Abbreviation for the package that is defined within the parameters of PKG in pkginfo file. It should be further bound within certain characteristics. I'll discuss that when I'm clear on that part.


CATEGORY (Defines Package Category) parameter in the pkginfo file precisely specifies to which categories a particular package belongs to. A package should belong to atleast either "System" or "Application" category. If a package belongs to more than one category, we need to specify the categories in a comma-separated list.


NAME (Defines the Package Name) is the full name of the package which as rightly assumed, is defined by NAME parameter in the pkginfo file. Specifying complete package names precisely is very important as system administrators often use package names to determine whether a package needs to be installed.


Lets steer a bit further and look ahead,

How to Create a pkginfo File

1. Using your favorite text editor, create a file named "pkginfo". You can create this file anywhere on your system.

2. Edit the file and define the five required parameters. The five required parameters are: ARCH, VERSION, PKG, CATEGORY and NAME.

3. Add any optional parameters to the file.

4. Save your changes and quit the editor.
   

This was not even a gyst. Let me go through, study and I'll be back again on this topic soon with my humble explanation; expecting to get the feedbacks and lessons which would surely share to my knowledge level too.

What does a Consultant DO?

My views are purely the outcome of my experience. Now this is something very interesting. I'm recently into "web-development-consulting''. So to comment upon, I would begin with saying, that consulting is an art where the power of communication, ideas, intellect and know-how of the concerned market are together driven towards the achievement of the ultimate requirement of the client, adding value to our service. Here, understanding the client's requirement is very important. The skills demanded by the position of being a consultant is tremendous but these skills alone wont help. Its like "I have a phone but no one to talk to". Yes I mean it right... 'being client-centric' is essential at every instance being a consultant. The bottom line says, "Being a consultant, is being client-centric".

But then, is that so very easy as we think? I wont comment on that, as it depends on the experience and expertise level of various tycoons of consulting industry, no matter in what. In every aspect of consulting, client plays the most important role. For the purpose of knowing the needs and core requirements of the client, we need to undergo a vast thought-process, we need to have an in-depth insight about the business goals of the client, how does it function, the circle of all the vendors with whom they work with, the vendor policies, outsourcing details, etc. The more clear and precise we have the information with us, the more we have the ideas "ready-to-sell". This comes not with a great liberation but a lot of sacrifice. But its not necessary, all the time that we need to know these since it also depends on the policies of the companies, if they would disclose these critcal information. So we need to be wise enough to understand and act as per the circumstances based on facts. There are 'n' number of factors which influences 'consulting', which gives you 'n' number of options.

When in a meeting for instance, with the client, nothing but a scribbler will do a great help. This helps you to jolt down the critical points and minute details that you may miss out while making some of the most critical decisions. I do very precisely remember a phrase told to us by my high school principal. He'd said, "A faint ink is much better than a sharp memory". So travelling back from the sweet memory lane and re-learning some school days lesson, the punch line here says rather screams with a pinch of salt to convey the message. The points that we write down when in a meeting helps us not to miss out any minute details that is being conveyed to us by the client, helping us to get to the root level of the requirement and thus better decisions. Does the job of a consultant finishes here? I definitely need some further insight into the same.

Service Desk: A process or a function?

Time and again I have come across many questions if 'Service Desk' is a process or a functionality. I completed my ITIL training recently. I was full of questions regarding the same. I filled the classroom with the clouds of confusion over this topic. Many students came up with the same questions and some of them advocated against the fact that "Service Desk' is a functionality. Now before I make this statement, I need to be very sure of what I am trying to advocate. Ofcourse the fact that the it is indeed a functionalilty as described in ITIL documents. But my answers to "Whys" are very clear.

First... what I realised practically from my experience is that a user is completely isolated from the problem of repeated calling and finding the right person for the resolution. 'Help Desk' serves as a single point of contact (SPOC) for all the issues to be reported. From here all the resolutions are provided. It handles all the incoming calls and escalates them to the second or third level of support only if badly needed. Service Desk staff consists of skilled and experienced IT technicians. Service Desk is also responsible for regular updates to the customer about the status of thier request (in other words, 'tickets' and the 'users' as known in corporate companies).

It is an important part of Incident management process of providing an operatinal single point of contacts to manage incidents to resolution. Two main focuses of the Service Desk are Incident control and communication. Again here communication plays a very important role. I have come across situations where the helpdesk co-ordinator in our company picks up the call for some issues and ends up with raising a ticket for some other issue. In this case when this ticket is assigned to the concerned IT technician, it creates the whole confusions leading to a total chaos. This results in customer (user) dissapointment and a prolonged downtime., which adversely affects the business outputs. This is how the very purpose of IT service management looses its complete definition just because of the lack of good communication at the first place.

So now this is very clear that Service Desk is indeed a functionality. Now the question is who plays the most important role in this functionality ?? Read on....

Incident Management

Incidents.. hmmm.... Although we use this term vastly in an IT Infra environment, do we really reallise the sense of it? Is the "Incident" and "Problem" all the very same?? We often make this common mistake of perceiving both these terms alike.

In ITIL, both of these has got an altogether different sense and has got its own place in the process-hierarchy. Incidents are the ones which relates to the issues that needs to be restored as quickly as possible as per the agreed SLA's (Service Level Agreements). It focuses on minimizing the impact on the business operations.

But where as, "Problem" is something which is an escalated part of it. When we have a lot many common incidents coming up again and again with an unknown error, it becomes a problem... "Problem Management" makes sure that we minimize the operational impact of incidents and problems which are caused by errors within the IT Infrastructure. It focuses on preventing repeated incidents from happening again and again, after finding out the root cause of the same.