Month: August 2010

  • Kill the Annual Performance Review

    Kill The Annual Performance Review

    I’ve been holding on to this link for a while, hoping to write more about it, but there’s really not much more to write, so here it is.  The author, Samuel Culbert, was making the rounds a while back – NPR, WSJ, etc. After hearing him and reading this article, I was tempted to check out the book, but from what I can tell, it’s pretty much summed up in his short interviews and articles. The book doesn’t seem to offer much more than the basic premise: that traditional performance evaluations emphasize all the wrong things and set up an unnecessary adversarial relationship between the supervisor and employee.

    Personally, I’m all for (and encourage) providing performance feedback, but the traditional yearly employee evaluation is a pretty poor way to do it. Read the article, search for Culbert’s interviews, or read his book (and let me know if my guess about it is wrong) if you want to know more.

    Another instance where “going through the motions” management is actually bad for employee productivity and morale and where a little more thought can reap great rewards.

    Aloha.

  • Is project management enough?

    I was reviewing some notes from a colleague’s previous class on project management when I came across the following lines that caught my interest:

    A business or organization cannot survive on project management disciplines alone.

    Project management is defined as delivering to time, cost, and quality.

    Staff development is seen as an overhead if converted to a project cost, but [is] essential for an improving workforce.

    Employee development, morale, work/life balance, and even preventive maintenance/upgrades: these are all long-term needs that can easily be viewed as short-term distractions in a project-oriented culture.   It is clearly of little or no benefit to a project manager to use valuable schedule and resources on these kinds of activities.  So, this is where the functional (line) managers need to step to the plate. They are the ones that have the responsibility to provide a talented, skilled, stable, and motivated work pool to the project managers.  They have to be the ones to make sure their staff development needs are met.  They are also responsible for the basic functionality of the systems under their control. Thus, time for both staff development as well as system upgrades and maintenance must be reserved and held back from project allocation.

    I’m not saying that these project equivalents be considered sacred cows or anything. The resources spent in maintaining a well-adjusted, skilled staff need to be justified in terms of losses that would result from the expected turnover if these employee needs weren’t met. Similarly, system upgrade and maintenance task resources need to be justified against the potential lost time once they fail or need to be replaced.  But in any case, the responsibility for forming and advocating these projects must be with the employees and their functional, not their project, managers.

    Not a really complex or novel thought here, but just another indication of a need for intelligent and thoughtful management that clearly understands its roles and responsibilities.


    Scot’s graduate advisor, R. Ed Nather, has been known to say:

    If it goes without saying, better say it twice.

    As time goes on, Scot finds more and more wisdom in that statement and applies it often. Defining people’s project and functional roles is a great example of the value of explicitly stating what everyone often implicitly assumes without checking to make sure everyone else is operating under identical assumptions.