Project Perfect - Project Management

Project Management for Kids

We have been working with AllPM to come up with guidelines for kids school projects and assignments. Often the school will ask for an assignment but not train the kids in how to approach it. AllPM and Project Perfect have been working for many months to help in this area. AllPM have an article on their site at http://www.allpm.com/modules.php?op=modload&name;=News&file;=article&sid;=1468&mode;=threadℴ=0&thold;=0 which provides more information or go to our student site at http://students.projectperfect.com.au/index.htm

Basics of a Project Plan

Having a piece of software does not make a well managed project. Users of Microsoft Project often don't understand how to set up a basic project. How do you name Tasks? Where do you put Milestones? Learn how to create a "technically correct" project plan.

Building a Quality Culture

Building a quality culture is not an easy task. This white paper talks about how to establish a quality culture in an organisation. and how to sustain a focus on quality.
To read the full paper go to http://www.projectperfect.com.au/info_quality_culture.php

Project Management for Kids (PM4K)

Ever wonder why your kid comes home from school with a project or assignment and no idea how to complete it. There are basics like dividing the work into chunks and setting a deadline for each chunk, or phase. The problem is teachers are never trained in project management. Why not start teaching 5 or 6 year olds the basics like setting milestones?
For years we have been promoting the issue and even devoted a site to it http://students.projectperfect.com.au/index.htm Unfortunately the education authorities pass out work, but don't know how to teach kids to do the work. Next time you have a parent/teacher interview, ask them what they teach your kids about project management.

People who just don't get it

A fairly spirited debate recently (and there were in fact spirits of an alcoholic nature involved) centred on whether there were some people who just did not get it when it came to projects. We have all at some time or other worked with someone who had no concept of time or scope They just bungle along seemingly doing ten things at once, without any clear idea of where they are going, or when they will arrive. The conversation was around nature or nurture. Were their brains just hard wired in a different way, or had they never learnt to manage projects?
I tended to the view that it was a nature thing. There are people who are colour blind. There are people who are dyslexic. Why not people who are unable to plan?
The counter view was that it has never been learned either because nobody ever bothered to teach, or the person resisted learning. The latter was based around the "Nobody tells me what to do" model.
Yet some of these people seem to achieve their goals. To the rest of us however it looks really, really painful.

Would anyone care to share their views on people who just don't get projects?

New white paper on why projects fail

This is a well researched study of the reasons for project failure, and what can be done to avoid the mistakes. It covers a range of research and draws it together to provide guidelines for a successful project. Read it at http://www.projectperfect.com.au/info_it_projects_fail.php

Marketing your IT Project

I came across a good article called "Marketing your IT Project" by Tom Mochal". Tom is a well known Project Management author and this is a particularly good article. It is worth a read.
http://techrepublic.com.com/5100-10878_11-5896886.html?tag=nl.e101

The biggest problem in project initiation

I was asked today by a conference organiser to provide some information about the biggest problems in initiating a project. They want me to talk at the conference and were trying to flesh out the topic.
After some thought, I said "The Sponsor". In my experience, the biggest problem is getting the person who is responsible for the project to understand what their role is all about.
This is in two dimensions. Firstly many sponsors have little idea why a project is different to any other department they might be responsible for. I have had one sponsor say to me "I don't know what you want from me. You are more demanding than any of my line managers." I had to point out that I was doing a non routine job. His line managers had clearly defined processes and procedures and they just tweaked the business process. I was creating it.
The second dimension was that the sponsor rarely sees the complexity of what is being created. I have a friend whos son designs F1 cars. He does the aerodynamics. Even though I am an F1 fan, I have little understanding of the complexity of the airflow of a nose cone in relation to the side pods. Yet if I were to manage the design of an F1 car, I would need to understand the level of complexity although not necessarily the engineering behind it.
To undertake a project with a sponsor who understands projects, and is willing to make decisions on the complexity is a joy. Unfortunately it is a rare occurance.

Cheating on Earned Value

I was alerted by Tristan Yates to an interesting article on how to cheat using earned value. Tristan recounts his experience with a project manager who worked the figures to cover up a problem. As Tristan points out, the project eventually failed, the PM lost his job, and fingers were pointed in all directions. It is worth a read. Go to http://www.cioinsight.com/article2/0,1540,1876479,00.asp

Software complexity

I heard some comments recently that made me think about system design in a totally different way. Someone made the comment that IT programs were becoming so large and complex, it was impossible for any one person to understand some programs. In particular they were talking about Windows.
I guess we all know that, but if you think about it, we may need to adjust our whole outlook to supporting and developing software. In most areas of human development, we start not knowing anything, and gradually learn more. Take nano technology. Twenty years ago the knowledge of nano could have been written on a stamp. Today it is a whole new discipline with millions of published words.
IT is different. We start with a simple construction - think DOS - and end up with such a complex beast that thousands of people work to make it secure. None of them know it end to end.
So if we are building a bowl of spaghetti, are there different techniques we should be using? Are there new paradigms that should be developed? Should we 'black box' components and only design interfaces? How do we isolate the potential variables from the bricks and morter? I would be interested to see how other people view the concept of the software understanding that fades to grey.