Search This Blog

Wednesday, September 26, 2012

How to move to consulting?

Once I was interested in consulting and started thinking to join any consulting organization. During course of the finding the nature of a consultant, I came to know following stuff which are basic requirement of becoming a consultant
You have to become an expert in your subject matter, Take on challenging projects, and Become creative in finding solutions to problems. Attend courses in areas you feel you are deficient, read up on the blogs, get involved in forums, read pdf / books on consulting (i.e. The McKinsey Way and Trusted Advisor, Dangerous Company on “infamous” cases by leading consulting firms.
Take a look at past project documents in your organizations. Look for the original request for proposal (RFP), your company’s response to the proposal and the final solution documents. Try to understand what the challenges were , how they were solved and what the client feedback was.
Work with your business analysts to see how they are capturing client requirements and how they are working with clients to get more information on areas that need digging deeper. Get involved in pre-sales activity such as preparing proposals, meeting clients along with the sales or account teams. Volunteer yourself in writing proposals to get some first hand exposure to “understanding what clients want, formulating a solution and influencing them to buy form you”. These are key skills. Read, understand and  practice the 10 important attributes of a consultant. Network in your organization at company events and seek out consulting practice delivery managers. Tell them about your interest in consulting and tell them how what you have done to prepare yourself.
Look at job listings in your company jobs database and apply. However, reaching out to practice leaders may be more effective.
Have a good future in consulting job!

Friday, August 24, 2012

Documentation as one of your deliverables

Document these sorts of things

  • Requirements (features): Early on in the project, you should define what the client wants the product to do in specific terms. You can generate some requirements initially from brainstorming, but you should also engage your client in nailing down specific use cases to ferret out more detailed requirements. Also, explore all of the edge cases and exceptions that you can. This document should evolve with the project, because you can never know everything up front. Make sure you keep it up to date, because it should serve as the basis for testing and user documentation. The requirements doc can usually become the system documentation at the end of the project.
  • Constraints: Make sure to express the limits imposed upon the project. What won’t it do? What minimum versions of other software does it need? What features that similar systems might provide are being intentionally excluded from this one? You can often include these constraints as part of the requirements doc.
  • Commitments: The project schedule needs more than a verbal OK, and so does the allocation of resources. Write it down, whether it’s your commitment or theirs. You don’t necessarily need a formal document — email can work, as long as you can verify receipt and keep it organized for quick retrieval.
  • Implementation: You should comment code, but only comment the non-obvious. You should assume that the person reading the comments is capable of reading the code, and avoid explaining commonly used algorithms or features of the language (unless they’re esoteric). You should explain “tricks” that might deceive the reader, and algorithms that may be difficult to understand. Most importantly, you should document your intentions — the “why” instead of the “what” or “how”.
  • Documentation: Yes, you should document your documentation. Provide a map, so when the next person comes looking for something, they’ll know where to look. This can be as simple as a single web page that links to all of the project’s related documents.

What thorough documentation provides you and your client

  • You know what you’ve got and what you don’t have.
  • You’ve set clear expectations, so you reduce or eliminate unpleasant surprises.
  • When someone comes along later to add a new feature, they can tell what’s going on (even when that someone is you).

Include documentation in your contract

Documentation doesn’t magically appear by itself, and I’ve never seen any evidence of the rumored Documentation Elves. So you need to allocate time in the project for writing documentation at all stages. Your client needs to be on board with that resource commitment, so include documentation as one of your deliverables in your contract. It’s a vital part of the product.

Sunday, July 22, 2012

Six keys to achieving excellence

We IT people, spends lot of time in front of the Screen, and thereafter, we start to forget small noticeable change in our attitude towards our work with clients which lead to non performance and less opportunity. Here I have identified 6 keys which will help to achieve excellence. I have found them most effective with my clients:
  1. Pursue what you love. Aha, everyone says the same, however it is true that passion is an incredible motivator. It fuels focus, resilience, and perseverance.
  2. Do the hardest work first. We all move instinctively toward pleasure and away from pain. I have found something which is called,  delay gratification and take on the difficult work of practice in the mornings, before they do anything else. That's when most of us have the most energy and the fewest distractions.
  3. Practice intensely, without interruption for short periods of no longer than 90 minutes and then take a break. Ninety minutes appears to be the maximum amount of time that we can bring the highest level of focus to any given activity.
  4. Seek expert feedback, in intermittent doses. The simpler and more precise the feedback, the more equipped you are to make adjustments. Too much feedback, too continuously, however, can create cognitive overload, increase anxiety, and interfere with learning.
  5. Take regular renewal breaks. Relaxing after intense effort not only provides an opportunity to rejuvenate, but also to metabolize and embed learning. It's also during rest that the right hemisphere becomes more dominant, which can lead to creative breakthroughs.
  6. Ritualize practice. Will and discipline are wildly overrated. none of us have very much of it. The best way to insure you'll take on difficult tasks is to ritualize them — build specific, inviolable times at which you do them, so that over time you do them without having to squander energy thinking about them.
That’s all from me for this week.