You are currently browsing the tag archive for the ‘Project management’ tag.

Really, not a fresh  subject.  Why on earth would anyone want to tell the world how important it is to communicate, yet another time?

Actually, after the recent plane flyover accident that cost the White House Military Director Louis Caldera his job, it is quite appropriate to write a few lines about the effective communication.

If you are initiating a change or a project of any scale, remember:

– to identify all stakeholders (those who will be affected by it )

– to plan communication: determine how you will communicate with them (time, frequency, means)

– to communicate as per the plan without fail.

Watch the video below to see how White House staff would benefit from memorizing the three lines above.

Business is about common sense, which is not as common as the name implies, but that’s a different story. If you are not happy about performance of your team, results, project outcomes, or whatever else, there is no need to engage in flagellation.

Just change, do what needs to be done.

In a recent workshop with a group of incredibly smart managers, someone told me about the need to improve  communication among the participants and asked an advice on how to go about it.

I said that they should talk to each other. There is nothing recondite about it.

Here is a timeless skit with Bob Newhart, which demonstrates the effectiveness of the “common sense” approach.

I recently answered this question and then thought it may be worth posting in the blog.

Question: What quality frameworks (ISO, CMMI, ITIL, etc.) have you used in your organization(s), and what pros/cons from each have you found in your experiences?

Answer: There are three key issues that I encounter time after time:

– Faulty belief that a framework (any of these) is a silver bullet for all and any problems. I have seen them applied to correct personality conflicts and dysfunctional leadership. I kid you not!

– Failure to customize. You gotta make it yours to work for you. An IT services organization I know lost customers because third line support found themselves compiling case documentation 80% per cent of their time. Resolved that, but not before some changes at the top.

– Falling in love with your methodology. This is not set-it-and-forget-it deal and you have to test your approach for relevance all the time. Is there a better way to do it? Are our assumptions still valid? A bank I know implemented user account management policies which require faxing (this was in 2008!) of a change form to the support centre. It takes 2-3 weeks to have a user set up. Meanwhile, the business has to put these people to work, so passwords are shared as a matter of standard practice. Formally, they have adopted ITIL. In reality, they are providing poor (if not dangerous to the business) service, having failed to re-evaluate their approach.

In 2008, McKinsey surveyed some 3,200 executives around the globe and found that only about one third of all change initiatives succeed.

In fact, it can be argued that this number is probably even lower, since “success” means different things to different people and humans are not terribly forthcoming with acknowledging failures.

I believe that most fiascos are attributable to the lack of accountability, a key ingredient of leadership. Being an instigator of change is not a comfortable position, as change itself is uncomfortable and, often, disruptive. To instigate change means abandoning the safety of the status quo, something that only strong leaders who feel responsible for the end result can be motivated to do on their own. Accountability can also be imposed externally (e.g. by the owner making the CEO responsible for the end result).

Strong leadership is always in short supply. The ownership of large corporations is dispersed among many shareholders who cannot demand accountability on their own, while corporate boards have proven to be ineffective. In public sector, taxpayers, likewise,  have few means of instilling the sense of accountability.

And since the perfectly effective governance is probably an utopian notian at this point, yet again it all seems to boil down to the question of strong leadership.

At a recent event, a man came over to introduce himself.  He explained that he was a project manager and wanted to “pick my brain on something”. I inquired about the kind of projects he typically engaged.

“Oh, system implementations with budgets of $1-2 million.”

It occurred to me at the time that project budget is a useless but commonly used metric. What does it tell us about the size or complexity of projects this gentleman runs? Nothing, for different organizations go about projects differently. Some throw money at it,  hire dedicated teams, buy the best equipment, and involve consultants. Others spend as little as possible  relying solely on internal resources, adding the project to a list of responsibilities for a few people within the organization. It is meaningless to compare the two projects on a basis of budget because the approach is so diverse.

Furthermore,  an argument can be made that the same project carried out on a strict budget is more challenging and speaks to the mastery of the project manager and abilities of his team. After all, which chef is more skilled, the one who prepares a delicious meal from a limited number of ingredients in a field kitchen or the one who whips up the same meal from a fully stocked pantry, in a restaurant kitchen with a crew of helpers?

The question on budgets is often posed in job interviews, but the truth is, you should never base your decision on the answer. This metric has no meaning and should not be used.

I wrote this article for ProjectTimes and it was published today.

1. It is best not to share the project plan with the project team as it leads to unnecessary and usually incredibly stupid questions.

2. Mandate that team members submit task duration estimates as precisely as possible: two decimal digits (e.g. 17.36 days) are usually sufficient but some projects may require three digits.

3. Strive to disperse project team over multiple locations: it greatly reduces the time people waste mindlessly chattering with each other.

4. In this economy, everyone ought to be able to work harder. Schedule tasks based on 10-hour days.

5. Involve the Steering Committee in day-to-day running of the project. They will tell you how much they like it.

6. When briefing the Steering Committee, it’s a good idea to declare all nearly completed tasks as completed. Ninety per cent is awfully close to 100 per cent and the Committee Members will feel encouraged.

7. Try to surprise your Project Sponsor every now and then. Rescheduling the implementation date, firing half of the team or changing the vendor half-way through should all be considered.

8. Status updates clutter mailboxes, so avoid them.

9. Get rid of those team members who disagree with you. You are in charge of a critical project and the last thing you want around is some worm questioning your decisions.

10. Don’t waste any time trying to understand the business domain. It is unimportant and is not your job.

11. A list of typical project risks can be easily obtained on the Internet. Don’t waste precious time developing it; this is merely a formality.

12. Act professionally: don’t engage in unrelated conversations with your staff and certainly avoid socializing with them. It is important to maintain a distance.

13. Information Technology is an exact, predictable field. If your programmers cannot write code without any defects, replace them.

14. To speed up negotiations with vendors, just sign their canned contracts.

15. Details are unimportant; the job of the project manager is the overall supervision.

16. Once the scope of the project is determined, ensure that it is impossible to change it.

17. A lot of people may claim to be project stakeholders. Feel free to ignore those you don’t like.

18. Encourage team members to decide for themselves what their tasks should be.

19. The best way to gauge the skill of a fellow project manager is to ask them about the largest project budget they’ve ever been responsible for.

20. Plan to release the project team on the day of implementation, to save money.

21. (Bonus) Forget that it’s April Fools’ Day and start typing an angry letter to the Editor. Remember that it’s April Fools’ Day when you’re on the third page of it!

You have probably heard about the CHAOS  study into project failures, now 15 years old but still often quoted and referred to. Since then, a few similar studies were undertaken by larger consulting companie, but they have offered little insight beyond what CHAOS report was saying.

If you read one of these studies, you will see that they go into estimating losses from derailed projects and you may notice that they only take very large projects into the considerations, those worth millions of dollars.

In my opinion, it is not the large projects that bleed money from organizations, but the smaller stuff, tens to (at most ) low hundreds of thousands in spend that can be authorized by mid-management because they “have money in the budgets to do it” .

Larger projects, which also fail spectacularly at times, are usually carefully looked into at the inception and measured agaist the strategic objectives. They usually receive enough attention from the C-level, which ensures good governance and strong sponsorship and project management. They are usually well funded. Usually is the key word in my assertions.

By contrast, smaller projects often receive little scrutiny in respect to their alignment with strategic business objectives, are often done on a whim, suffer from the lack of sponsorship, and are  poorely managed. In my experience, such projects die in droves and with little visibility, if any.

To ensure prudent cost management today, management must divorce itself from the notion that budgets are given to them to be exhausted, but this notion has to be subscribed to and instigated from the top of the organization to be successful. The seemingly insufficient trickle of waste from smaller project turns into a sea of waste which can be prevented.




website www.bizvortex.com email ibogorad@bizvortex.com phone (905) 278 4753

 

Bookmark and Share