Innovation Creators (which I’ve started reading regularly) has an interesting and broad article about micromanagement. The article touches on micro- versus macro-management in industry, relevance to enterprise blogs and economy.

Having recently suffered through the ultimate micromanagement experience, and now working for a true macromanager (referred to as Theory X and Theory Y managers respectively) this article outlines the differences very well and points to some other interesting resources on the topic.

management, project management, theory x, theory y, cat herding, micromanagement

When talking with Scott, a student who is doing some database work with me this semester, the topic of hourly pay versus salary pay came up. I mentioned a simple way to estimate yearly income from hourly rate on the fly.

Let’s say you are offered a job for $11/hour. If you assume you work 40 hours a week for 50 weeks a year you can simply double the hourly rate and that will be the yearly income in thousands, so $11/hour = $22,000/year.

I figured out this method years ago when I was job hunting in college so I could easily compare hourly and salary positions. Of course you’ll want to figure benefits and possible overtime into the final decision, but this gives you a quick idea.

This method works because 40 hours per week multiplied by 50 weeks makes for 2,000 working hours in a year (assuming two weeks of unpaid vacation). Multiplying by 2,000 is the same as multiplying by 2 then by 1,000 so that’s exactly what we do.

Cube FarmAnother common term heard around the office is “Cube Farm”. A cube farm is not necessarily a terrible thing, but they need to be planned properly.

Definition: An office filled with cubicles. This really boils down to a room full of people at desks with little more than a smattering of upholstery between them. Cubicles are typically composed of fabric, metal and press-board. Cubicles vary from the full six foot walls on three and a half sides, down to a scant four foot tall partition simply separating you from the next person, if only from the waist down.

When do cube farms work?
In my experience there are two key factors which make cube farms viable, and yes, even beneficial. First, the people within a close proximity are doing very similar tasks. A group of support technicians in a cube farm can generally feed off each other’s knowledge and offer a high quality of support.

The second factor that often plays into cube farm success is that traffic (both walk-in and phone) from outside people is kept to a minimum. Support is the exception to this, however a software developer in a cube farm with support people will be constantly distracted by the support chatter and walk in questions.

To be effective cubes must be planned around the teams and workers they are meant to be occupied by. Cubes put up with little planning just to create a place for employees to work rarely if ever benefit their residents.

When do cube farms fail?
As mentioned above, cube farms often fail due to lack of planning. I am currently working in a cube farm where four different people serve three different functions, all in about 200 square feet.

Another key factor is the height and coverage of the cube. A six foot tall cube wall which completely blocks direct view of coworkers is best. This typically means cubes are almost completely enclosed with just enough space to enter and exit. Cubes with short walls that allow you to see others over them are generally ineffective, and having only one or two walls is not much better than having none.

The two biggest wastes of time in the office are visible distractions and audible distractions. Good cube farms with high walls, workers who spend a minimum of time on the phone, and in an area where foot traffic is minimal can work out very well. Cube farms which are small, poorly laid out, and with no consideration given to the function of the occupants will result in lost productivity, irritability and personal conflicts.

For more information on cube farms check out wikipedia.com’s article on the topic.

Technorati tags: , , ,

In fall of 2004, Zach Tirrell and I developed these steps to lend consistency to the evaluation of products to met the technological needs of our constituents.

In building this, our main concerns were that all potential users and stakeholders were identified and involved before product choices were discussed, that open source and homegrown applications be considered alongside commercial solutions, and that all peripheral costs (support, upgrades, hardware, training) be considered as part of the price of implementation.

Sadly this did not gain widespread adoption in our department. Despite that, some of us have followed these steps and found the process useful.

In the future I may elaborate on these steps; however I consider most of them self-explanatory. Please feel free to post comments if you have any questions about these steps.

10 Steps to a better product choice

The following steps are designed to be used in conjunction with normal project management procedures to ensure due process is given when considering technical solutions.

  1. Determine initial user base and stakeholders
  2. Determine requirements and dependencies (desired features, architecture, budget, etc.)
  3. Re-evaluate user base and stakeholders
  4. Repeat step 2 for new user base and stakeholders if necessary
  5. Identify 3 or more potential solutions. Consideration should be given to what products are used in other similar institutions. Commercial, open source, and homegrown solutions should all be considered
  6. Compare the delivered features of each potential solution against the defined requirements and dependencies and list any additional benefits
  7. Estimate the implementation costs and timeline for each potential solution. Estimate ongoing costs including licensing, server upgrades, IT support, helpdesk, product upgrades, patches, etc.
  8. Compile report including return on investment, costs, requirement/dependency fulfillment, and features
  9. Choose the solution which best fits the requirements and dependencies
  10. Implement the new product

project management, technology, software, software evaluation, product development, management

« Previous Page