Desktop Security Software- An error has occurred; the feed is probably down. Try again later.
Is it more fun to be a Project Sponsor or a Project Manager?
Posted in Software Jokes
Leave a comment
The Catapult in Software Project Meetings
The ‘catapult’ or ‘butterfly’ body language is often displayed in project meetings.
Why is body language important to a project manager? Well, once you get past a certain level of experience in managing projects (or managing in general) you can concentrate on how to become even more effective. And one way of doing that is to improve communication, facilitation and collaboration skills. Watching and reacting to body lanuage helps with these activities enormously.
So what is the ‘catapult’ in a body language context? You will recognise it instantly. It is almost always done by men, very rarely women:
It is the placing of both hands (interlocked) behing the head or neck with elbows out. Usually the person is seated.
It occurs when the person is feeling superior (“untouchable” with confidence) on the subject under debate. Or just generally feeling in charge and superior to everyone else present.
Now that you know you can watch out for it and use it your advantage. You’ll find that often managers will display this body language in front of subordinates, but rarely does it occur the other way around. And if it does, there may be issues to explore and resolve there.
Posted in Body Language, Management Theory
1 Comment
Why an extended enterprise architecture model is key to corporate transformation programmes
Enterprise Architecture
Enterprise Architecture - BADT Overview
Most architectural frameworks centre around at least four inter-related domains (see diagram above), from which hangs off ever increasing organisational (enterprise) detail.
Many frameworks avoid, or at least do not treat with the same importance, the people aspect. The way people, staff, colleagues, resources, however they are referred to, are managed, collaborate and influence processes are just as important, if not more so, than the “BAD-T” jigsaw above.
Extended Enterprise Architecture
To get from an “As-Is” to “To-Be” Enterprise Architecture (or A2B) in a usually restricted time period, the core elements, even at the very top level abstracted model shown above interact with each other significantly. For interact, also read conflict!
In Business Transformation programmes, depending on who has set-up the initial plan, much focus can be placed on some or all of these elements – Business Processes, Application Architecture, Corporate Data, underlying Technology platforms and staff resources (the glue and the oil that keeps it all working).
The key to effective planning around these domains is to blend the main objectives of the transformation into a reasonable understanding of the traditional BAD-T set-up. This will give the top level activities and goals that need to be driven into to extract more detail and issues.
Focusing on only one or two areas, for example resources and technology can leave a lot of unconsidered risk within the business transformation programme.
Software Project Survival Guide – Book Review
I’ve read a fair few books on software projects and this one initially escaped my notice because of the title. It has a bit of a “defensive” title, so I thought it might be one of those books that advises on how to recover failing or soon to collapse projects. Or it was for people who just need to get through one or two projects that had been dumped on them.
But it isn’t really for those situations at all. It is a very pragmatic book, filled with software project experience gained from the real world.
The main thing I took from this book, and I fully agree with its reasons why, is to create fully ‘wide’ prototypes (in terms of UI interaction with the User), but low in depth (in terms of working functionality). For systems that have a lot (or even a reasonable amount) of human-computer interaction, this is by far the best way to define and later control software application progress.
In one project I did put forward this point of view to the development team. It didn’t go down too well. I think they all saw this as throw away work as the technical architect hadn’t even decided what technology the UI client would be.
Eventually I got talked down from this approach by the TA and other team leaders. It was a mistake. I absolutely should have kept going with the “wide-but-shallow” prototype, irrespective if it was throw-away or not - it would have been in this case, but the scoping, planning aspects and the User feel-good factor – their involvement with the design process, would have far out weighed the throwing away of the prototype.
This book is great. Buy it and read it if you routinely manage software projects. Another lesson learnt – have the courage of someone elses convictions – if that someone else is Steve McConnell, the author of this book. ISBN 1-57231-621-7.
Full 5/5 score from the Software Project Manager
Available from: http://rockhardprojects.com/Software_Project_Book_Shop/Software_Project_Book_shop.html
Posted in Software Book Reviews
1 Comment
X & Y Theory
Which gets the best results from a team, a software team – a PM who is dictatorial, assumes everyone is a slacker, and that people only turn up at work to do as little as possible, knows that nearly all people know less than him or her, shouts a lot and uses all ‘stick’ and no ‘carrot’?
Or a PM who assumes most people genuinely will try to do their best in most situations and will adopt the best way forward within their ability to satisfy assigned tasks and usually will have their team’s best interests at heart?
The Apprentice Vs Star Trek? You’ll see the metaphor if you’ve watched both TV shows … The PMs in the Apprentice Vs Captain Picard?
The most powerful motivating phrase a PM once said to me, “that’s not like you Ed, you usually have it all sorted for me”.
Doesn’t sound like much does it? But it made me feel both good and bad at the same time, but mostly made me want to sort the situation out for the PM and for it not to happen again. Obviously I respected the opinion of the PM otherwise it wouldn’t mean anything. But as I did, it had a powerful, low key, impact.
To get back off that tangent, I think neither the X Theory (dicator PM, everyone is lazy) or Y Theory (everyone will always do their best anyway) is correct. It depends on the situation to hand and the people involved.
What I do know is, routinely polarising to either extreme won’t work. As a lot of spiritual people observe, the middle way is best.
It pains me to say it (because I love the tortured-soul super hero films), but being in the X-Men group won’t work as a PM.
Posted in Management Theory
Leave a comment
Hard Core Elite Software Teams
The first common perception of a great self-directed software project team is that it is insular and arrogant.
It will be viewed as a closed clique, misunderstood and distrusted.
Unless the team makes great efforts to be open and generous with other teams and superiors (which it never will do without constant and significant ‘persuasion’), the overriding view of the team will be that of arrogance mingled with dislike.
Ultimately, no matter how great the results, the team will be taken apart … to spread the knowledge.
Trust me, if you want to keep a very productive software team together, don’t be too insular. “Forming, storming, norming, performing” – the first three are all well and good, but they are just phases to get through – constant performing is much more fun and, well, prodcutive!
Posted in Project Politics
Leave a comment
