Original URL: http://www.theregister.co.uk/2010/12/03/pm_regcast_faq/
PM survival guide: The Director's Cut
Our Regcast left some unanswered questions
Project management There were so many viewer questions for our project management Regcast on 24 November that we couldn't possibly answer them all in 60 minutes. Some of the best questions we could answer, but not in enough depth to do them justice. So we recalled panellists Dave Vile and Bob Walker afterwards and forced them to give us the answers you need.
Shane: Isn’t agile just a way for clients to ask for twice as much in half the time?
Bob Walker: It is if you let the client dictate the way you run the project. It’s about scope and control, and about delivering what’s required.
Dave Vile: It’s the business of the project team. Agile is a way of achieving something. It’s about how you do it, not what you do. I agree.
Austin: What are your thoughts on AtTask’s plan to release the “first true social work management platform?” Does such a concept already sound similar to software you have used in the past? Do you think such a concept fits in with the idea that traditional top-down or command-and-control project management does not work with today's workforce?
BW: I’m slightly biased: my view is that PM needs somebody to lead, someone has to carry the can at the end of the day. It’s not social as in all these Facebook-type things out there. You still need command-and-control structure, otherwise things never get delivered.
DV: I agree. The caveat is that collaboration is a good thing. Our research has found that development environments that have a high degree of collaboration capability made available to developers tend to perform better. But that is not a substitute for the right kind of project structure and the right framework.
If you have a couple of coders trying to figure out the best way of doing something they can very quickly communicate with each other and exchange ideas within the scope of a specific task. Collaboration has its place but it’s not a substitute for structured management.
Steve: How specifically does EPM associate the issues older versions of MS Project suffered from when trying to address effort and duration for planning and tracking tasks and deliverables?
BW: EPM is the name for Project Server, Project Professional and Project Wed Apps. These tools build a solution that allows the user to create schedules which are held within the Project Server databases. One of the issues I have seen in the past is that users are not really aware of the way project activities (or tasks) are created.
There are three task types: fixed duration, fixed work and fixed units. Of those three, fixed duration and fixed units can be effort driven as well. Therefore users had to be aware of what task type they were using and the relationships between those task types. Often we put in markers on deliverables and make them a milestone, for example. Now with EPM we start to do things that change the way we manage our projects, programmes and portfolios.
For example, data confidence. We can look at the quality of the project schedules in the database and understand how they are constructed, identify weaknesses: tasks with no predecessors or successors, milestones with no dependencies, resources on summary tasks or milestone, for example. And identify how to correct the schedule to improve the quality of the data. We can easily see that no baseline has been set, that the schedule is not up to date, and so on.
We can now, using EPM, identify which milestone or tasks are deliverables and link those through for reporting within Project Web Apps, and link corresponding documents or drawings to that deliverable
With a centralised solution comes a single view of resources, thus making sure again that resource management is carried out correctly
I often found in the past that better training delivered better results as well. Too many of us (me included) were self-taught on Microsoft Project. We use what we know, not what the project needs.
But the key thing that EPM brings is that only those people in an organisation who build and manage project schedules will use Project Professional, thus you get the right people using the right tools. The rest of the organisation that needs to interface with the project will come in with the lighter-weight Project Web Apps to access the specific data they need to see according to their position within the project.
Mike: For IT projects, we increasingly find agile methodologies (predominantly Scrum) to be more effective than waterfall. What are the panel’s thoughts on this?
DV: In our experience and based on recent research into agile that statement can be true, particularly for smaller projects. But usually the overarching framework is in place to give the team the right kind of objectives. The feedback we often get is that agile is good and there is no arguing with that, particularly for smaller environments. But you usually find that there are stories of it not working where people have seen it as a substitute, rather than as a way of working within a properly managed framework. It can be applied to larger environments but it’s actually a lot harder to do it. Distributed environments can be a lot harder too.
BW: I also believe that people are getting IT mixed up with development. You may have waterfall as your methodology and agile as your development methodology. It doesn’t have to be exclusive, it can be one and another.
Fred: What do you mean by content management?
DV: Whatever you were to call it, what is important is central storage which allows you to categorise and organise the various types of documentation that are important on a project and allows you to navigate or search. Then the other typical requirement is workflow, including the capability for alerting, approval and versioning when a document is changed or signed off. These are typically the things that are important.
Darren: Does the panel favour a project management methodology, such as Prince2 or PMI? Is it followed precisely or do you create your own hybrid for your projects?
DV: Our experience and research indicates that if you are controlling projects largely in-house most people apply the 80/20 rule. They don’t blindly follow elements of a methodology just because it says you should. The first thing is understanding the spirit of the methodology. Where people try to work to the letter of the methodology it tends to be either because they are working with a third party and there is some kind of a formal contract which dictates the way things need to be done, or when the methodology is part of some kind of compliance framework for regulatory purposes.
BW: I would add that talking to many customers I conclude that it has to be something the organisation owns. Whatever it is, it has to be something the organisation owns.
DV: Yes you have to agree on it. You can be totally compliant but if you miss the point it’s ineffective.
Clive: Do you have any recommendations on how best to project manage a new business intelligence implementation?
BW: I think it’s back to basics. Identify the scope, identify what the customer or sponsor really wants and make sure you deliver what they are really looking for. It’s basic project management.
DV: The main reason business intelligence projects tend not to deliver is because people haven’t understood the problem they are trying to solve in the first place. For me it’s a case of really defining what you are trying to achieve. For example, when you go and talk to the stakeholder, quite often they can’t even articulate what key performance indicators are relevant, and without understanding what indicators are important you don’t know what you are aiming at. So it is about really focusing on the requirements, make sure you have really nailed them. You almost have to go searching for stakeholders that haven’t declared themselves. Once you have the requirements in place the rest is standard stuff. ®