Technical term for a brain dead management technique?

[RichardCranium]

Ineffectiveness is the oppostite of effectiveness. Measure one and you have the other.

Did you make that up? It's genius!

[Spacecadet]

Did you make that up? It's genius!

Think of me as the lucky typewriting monkey

[RichardCranium]

Does micromanagment of this nature actually work? Surely if you have decent profesional people then you do not need to check they actual did any work yesterday and then check they are going to do some work today? And in fact the very act of checking and re-checking is more demotivating than laying a cable in their morning cuppa?

It depends upon the question. When I take on a new team and the work is allocated and under way I use this: "Is there anything or anyone preventing you doing what you think you should be doing? Is there anything you need or anything I could do to help? Then I shall ask again tomorrow. But remember, if a problem arises tell me immediately so I can fix it before tomorrow." If I get a flippant answer like "Yeah, a cup of tea" then I go and put the kettle on, make everyone tea, then ask the same questions again.

I think the book was called The One Minute Manager.

When all is going well an entire team can be supervised & managed in 5 to 15 minutes per day. When it isn't I know I will get to hear about it early. (I also make it clear that if I find out about a problem from someone outside the team first, I'll kick someone's arse.) I don't think that is micromanaging.

Micromanaging is "Why did it take you 9 hours to write that routine when you said 7?" That kind of thing drove me mental when I was a programmer: "Because it has never been written before, you idiot".

It is a derivative of a technique that successful project managers use called "walking the floor". It's not a very difficult technique to learn, but central to it is the ability to listen with two ears, and to speak in a clear voice. It's amazing how many people fail to identify or grasp the importance of the technique, but then it's not taught in any PRINCE2 manual, and is not part of any client governance process that I have seen.

It's also amazing how often a project manager caught walking the floor will get told off by a programme manager or programme director for not working. "If you are not at your desk fukcing about in MS Project, you're not managing the project. Now go and spend 3 days writing me a status report and if I see you leave your desk again you're in trouble."



Project management is a tulip job.

[minestrone]

I noticed last week that our scrums just sound like what AA meetings probably sound like...

"I had a really tough day Yesterday, managed to get some help from people on the team and got through it, much more positive today, got my objectives set up"

"Nice one, remember the team is always here to help, your objectives are our objectives"

I really think I could be more productive getting in at 9 and doing a burst of coding rather than having a forced break at 10 for a daft group hug.

[Spacecadet]

Micromanaging is "Why did it take you 9 hours to write that routine when you said 7?" That kind of thing drove me mental when I was a programmer: "Because it has never been written before, you idiot".

I'd say Micromanaging is when you tell the PM that to fix problem X will take 7 hours, then 30 minutes after sitting down to start work on problem X he asks "hows it going" in a rather vague way wanting a status update on problem X which you're still trying to get your head round before putting finger to keyboard.

[RichardCranium]

he asks "hows it going" in a rather vague way wanting a status update on problem X which you're still trying to get your head round

and the PMs are getting that from the programme managers and they get it from the programme director and he/she gets it from the Director and he/she gets it from the MD and not one of them does a day's productive work for the organisation.

This past few years I have flatly refused to provide "status reports" to anyone but my project boards. "If you want a status report, I'll email you last month's highlight report".

In fact, hurrah for PRINCE2. "Sorry, there's no process for giving you a status report in my PRINCE2 manual. You could submit an Issue for the attention of the Board at next month's meeting, I suppose. ".

[Zippy]

I suppose what most of the previous comments are alluding to (including my own), is that there is a perception that some simple, handle-turning method of delivering a project exists. Developers who have been brainwashed in to a particular methodology suffer from this too.
There is no "one true way". I've tried it all ways believe me, and have come to the conclusion that - as the man in the middle - you have to be hard-nosed, thick skinned and up for a fight.
I kind of like Scrum because where you are in that section of the project is very visible, it can be easily mapped to tasks on the "grand" project plan and when it starts going wrong you can spot and fix it quickly. The scrum master needs to be hard-nosed, thick skinned and up for a fight.

[shoes]

It is one of the many reasons why software is sh1t and nothing works.

Development is an art, and as such will never fit in well within the corporate machine. These 'methods' will come and go as they always have done and none of them will 'work' because you cannot enforce a process on a creative activity.

A developer is not an extension of a machine where a handle is cranked and out comes your product. All these methods are based on the assumption that that is true, so all these methods fail.

A project manager would visit van gogh 50% of the way through the allocated time for the sunflowers painting to be finished and seriously expect there to be half of the sunflowers fully painted and precisely 50% of the vase painted from left to right ending in a vertical line.


Tell us what it needs to do, give us an architecture in which to do it, leave us to do it, it will be ready when it's ready. If it makes you happy, draw some charts with project. Don't be suprised when reality doesn't match them.

[Zippy]

It will be ready when it's ready won't work either. You can't expect people to leave you (us!) alone for an indefinite period. The value of closely monitoring the state of a project is that when things go wrong
a) the customer expectations can be managed and
b) help can be provided to get it fixed.
That's much better than leaving it until a week before delivery.

Oh and btw - as a dev you tell them how long you think it will take to do (see Balls of Steel )

[Spacecadet]

Tell us what it needs to do, give us an architecture in which to do it, leave us to do it, it will be ready when it's ready. If it makes you happy, draw some charts with project. Don't be suprised when reality doesn't match them.

Its not the Sistine Chapel and companies cannot wait an indefinite period of time for software to be finished. It costs money as it's being built and whatever cost savings are being made by the software are being lost whilst waiting for it.

I've seen what happens when development teams and suppliers are left to their own devices. Not much gets done, projects get cancelled (not throwing good money after bad) and people loose their jobs.