Alik Levin's

Clarity, Technology, and Solving Problems | PracticeThis.com 

December, 2008

  • Alik Levin's

    "The Most Important Act In Consulting Is Setting The Right Fee."

    • 3 Comments
     Alik Levin    This is what Gerald M. Weinberg writes in his book Secrets of Consulting: A Guide to Giving and Getting Advice Successfully.

    The book is full of great advices to consultants like myself and to those who hire consultants. 
    Weinberg discusses many other topics spiced with stories from trenches. But in this post I am focusing on monetary part of consulting.

    Related Materials

    Here in Microsoft Services Organization there is clear separation of who does marketing, sales, operations, and who delivers the service as an opposite to freelance consultant or small consulting firm. Everybody is crystal clear aware of what each team member does, how she does it, and most important why she does it. All the team members work in synergy in order to make sure:

    • Marketing is targeted to most profitable sectors.
    • Business is growing by selling more.
    • Team is capable to deliver the services being sold.
    • Team is capable to deliver world class services to highest customer satisfaction.

    On other side, when the team is not in synergy it suffers...

    These are the few anti-patterns I witnessed:

    Wishful marketing

    This is about marketing services that cannot be delivered to the highest customer satisfaction. Weinberg's writes:

    "We can do it - and this is how much it will cost".

    I only hope the emphasis here on "We Can" vs. "Will Cost".

    Selling no matter what

    Sometimes sales folks are eager to hit their numbers and just sell services without making sure there is a proper resource available with a relevant skills. This might lead to the situation where many service packages sold with a very low price making consultant who delivers it a very cheap deal. During few of my service deliveries I found out my work was completely ignored only because it's been done too quick (read "cheap") without major resource investments. Few days after I got to know another consultant was hired to do the same work. I reviewed the recommendations - they were identical to mine. I also got to know that the service fee was few times higher comparing to what was charged for mine... The other guy's report was fully implemented. This is what Weinberg writes:

    "The less they pay you, the less they respect you".

    Committing to deliver something you can't

    This situation might be due to the desire to win another customer, arrogance, recklessness, or incompetency. In any case the customer is left extremely unhappy. I cannot remember Weinberg's exact quote but I think it goes along something like "if you weren't able to deliver on your promise don't take the money". Sounds crazy but true. I did such mistakes in the past and I expect to make some more in the future. Admitting my mistakes and not charging the customer created the trust and gave me a second chance - something I would not get the other way around.

     

    What are your lessons learned from charging your customers?

     

    This post is made with PracticeThis.com plugin for Windows Live Writer

  • Alik Levin's

    Software Release Management - The Questionnaire

    • 1 Comments
    Alik Levin    Have you been involved with Application Lifecycle Management consulting? Have you helped to build solid Release Management process? If so I need your insights.
    I started my research with a quick search and I have stumbled on the following article that perfectly matched my online search: 7 Ways to Improve Your Software Release Management. I have read the article and tried to reverse engineer it in form of questionnaire. Asking the right questions helps to identify the gaps and build the work breakdown structure and the associated tasks. Here is my questionnaire. What questions would you add? What resources you'd recommend?

    1. Understand the current state of release management.

    • What is the current release cycles?
    • Are there any? Is it ad-hoc all over the board?
    • How many teams are there?
    • Who’s the team leads, the developers and how do we know what they are doing?
    • How requirements are generated? How requirements are tracked?
    • How requirements are translated into designs? Who does it?
    • How the dev team does know what to do/develop?
    • How the dev team tests functionality?
    • How the dev team test for non-functional requirements (security/performance)?
    • How do they perform system/integration/regression tests?
    • How the team gets sign off to roll the new version into production?
    • How the team tracks release notes?
    • <<your question goes here>>

    2. Establish a regular release cycle.

    • What is the release cycle today? Monthly? Quarterly? Weekly? Ad-hoc?
    • When is the next release date?
    • When was the last release date?
    • Is there any pattern in past release dates?
    • What would be the most realistic release cycle? Weekly? Be-weekly? Monthly? Quarterly?
    • What are the usual road blockers for the release? Performance test, security approval, QA? Other?
    • <<your question goes here>>

    3. Get lightweight processes in place. Test them early and review them regularly.

    • What’s the smallest change that can make the biggest impact now?
    • Why not publish simple chart of the release cycle so that anyone can see there are [no] gaps?
    • Why not establish team site to concentrate release artifacts?
    • Why not create team site for developers with skeleton projects to bootstrap from?
    • Why not create team site to manage Virtual Machines allocation among developers?
    • Can we do a dry run of the release management process now?
    • <<your question goes here>>

    4. Establish a release infrastructure early.

    • Once dry run is made we know the gaps - can you list it?
    • Do we know the resources needed to fix the gaps? Short term and long term?
    • <<your question goes here>>

    5. Automate and standardize as much as you can.

    • How can we automate dev environment build process? Who cares the most? Get them onboard.
    • How can we automate creating app bootstrap? Who cares the most? Get them onboard.
    • How can we automate version build process? Who cares the most? Get them onboard.
    • How can we automate unit testing? Who cares the most? Get them onboard.
    • How can we automate performance testing process? Who cares the most? Get them onboard.
    • How can we automate security testing process? Who cares the most? Get them onboard.
    • <<your question goes here>>

    6. Establish positive expectations.

    • Who owns release management? Set formal owner.
    • How to get the team to buy into the idea of formal release management?
    • What are the metrics to make sure the process is followed?
    • <<your question goes here>>

    7. Invest in people.

    • What each team values?
    • What's the most important thing to the managers?
    • What's most important to the project sponsor?
    • What's most important to the customer/end user?
    • <<your question goes here>>

     

    This post is made with PracticeThis.com plugin for Windows Live Writer

Page 1 of 1 (2 items)