The downloadable version of this article is available here:
http://techrepublic.com.com/5138-10878-5991783.html
Have you had to contend with a project manager who overreached their authority as described in the article? What was the result? What did you learn and more importantly, what did the project manager learn?
Discussion on:
View:
Show:
In many years in software development, the biggest problem I have seen which reduces quality is the "additional" requirement which gets tacked on after the construction has begun, and in some cases after user acceptance testing has started.
Basically, it throws the schedule off - in development and QA.
James
Basically, it throws the schedule off - in development and QA.
James
I agree that's a challenge -- however, I see that as more of a requirements miss than an active action by the project manager.
Sometimes it is the result of an indequate requirements gathering, sometimes it is caused by a long project where the environment changes as the project goes on.
But sometimes its just sheer stupidity - the idea that hey, just thought of something new, lets add it in because the project is still active. I don't let the project managers off the hook here either -they should be pushing back as much as possible.
James
But sometimes its just sheer stupidity - the idea that hey, just thought of something new, lets add it in because the project is still active. I don't let the project managers off the hook here either -they should be pushing back as much as possible.
James
Establish a practical process - crystal clear analysis, design, dvelopment and testing process which takes into account individual characteristics of each team.
Team characteristics are very important - different teams require different phases and work definitions and activities based on several characterstics, not the least of which is the technology.
I've found that a practical process(as against an impractical process created to say "We are all about process" or just to say "We are xxxx compliant" ) takes away a lot of effort and uncertainity in projects and even in the planning phases.
The first project might be a little painful but once the process is established, you'll be pleased with yourself.
Of course, goes without saying that different kind of projects will require different processes to be modeled and enacted.
There are various tools coming out which highlight the importance of having aprocess. I believe there is one called IRIS (I forget the company that makes it) that is gaining attention for its process modeling and enacting (automatically enforcing the process in your team) capabilities.
I believe IBM is also coming out with one soon.
Team characteristics are very important - different teams require different phases and work definitions and activities based on several characterstics, not the least of which is the technology.
I've found that a practical process(as against an impractical process created to say "We are all about process" or just to say "We are xxxx compliant" ) takes away a lot of effort and uncertainity in projects and even in the planning phases.
The first project might be a little painful but once the process is established, you'll be pleased with yourself.
Of course, goes without saying that different kind of projects will require different processes to be modeled and enacted.
There are various tools coming out which highlight the importance of having aprocess. I believe there is one called IRIS (I forget the company that makes it) that is gaining attention for its process modeling and enacting (automatically enforcing the process in your team) capabilities.
I believe IBM is also coming out with one soon.
I agree that the up front analysis process is key. When the processes are well defined, it is great. The problem comes when the process was designed for one type of project and is ill-fitting for another. I recently had a situation in which the process was designed for starting a new facility site and customer from the ground up. When one has a longterm customer with established business processes, a major system upgrade doesn't fit particularly well. If your management doesn't recognize the differences and allow for some tailoring of the process, the project effort will almost inevitably go off the rails.
Another critical component is composition of the project team. It is absolutely essential that the business stakeholders be strongly involved and committed. When that is lacking, requirements gathering becomes a nightmare of missed processes and wrong assumptions particularly if the business managers are new or simply ill-informed.
Another critical component is composition of the project team. It is absolutely essential that the business stakeholders be strongly involved and committed. When that is lacking, requirements gathering becomes a nightmare of missed processes and wrong assumptions particularly if the business managers are new or simply ill-informed.
I agree that the up front analysis process is key. When the processes are well defined, it is great. The problem comes when the process was designed for one type of project and is ill-fitting for another. I recently had a situation in which the process was designed for starting a new facility site and customer from the ground up. When one has a longterm customer with established business processes, a major system upgrade doesn't fit that process particularly well. If the project manager's own management doesn't recognize the differences and allow for some tailoring of the process, the project effort will almost inevitably go off the rails.
Another critical component is composition of the project team. It is absolutely essential that the business stakeholders be strongly involved and committed. When that is lacking, requirements gathering becomes a nightmare of missed processes and wrong assumptions particularly if the business managers are new or simply ill-informed.
Another critical component is composition of the project team. It is absolutely essential that the business stakeholders be strongly involved and committed. When that is lacking, requirements gathering becomes a nightmare of missed processes and wrong assumptions particularly if the business managers are new or simply ill-informed.
One of the trends that is reducing the friction between software development and project management is agile development.
Agile development methods (for example XP - Extreme Programming, and Scrum) make heavy use of timeboxing to the level of 1 to 4 week development cycles. These short cycles eliminate start-up inertia and force early integration. Testing cannot be deferred, in fact, the Test Driven Design approach brings testing front and center, a true peer of development, not a lesser after thought.
The short time-cycles also allow numerous chances to adjust requirements and give a better framework for deferring or eliminating requirements of lesser improtance. When customers can see a growing set of met requirements instead of merely an "end" date, they become much more cooperative in trading off features and schedule time and cost.
One of the lessons being learned is that the waterfall method, trying to define the requirements to the perfect system, coding those requirements, and then testing the whole thing is not a scalable approach. An iterative approach of building an absolutely minimalist baseline with small enhancements added quickly in succession provides a much more effective and manageable software development approach.
Agile development methods (for example XP - Extreme Programming, and Scrum) make heavy use of timeboxing to the level of 1 to 4 week development cycles. These short cycles eliminate start-up inertia and force early integration. Testing cannot be deferred, in fact, the Test Driven Design approach brings testing front and center, a true peer of development, not a lesser after thought.
The short time-cycles also allow numerous chances to adjust requirements and give a better framework for deferring or eliminating requirements of lesser improtance. When customers can see a growing set of met requirements instead of merely an "end" date, they become much more cooperative in trading off features and schedule time and cost.
One of the lessons being learned is that the waterfall method, trying to define the requirements to the perfect system, coding those requirements, and then testing the whole thing is not a scalable approach. An iterative approach of building an absolutely minimalist baseline with small enhancements added quickly in succession provides a much more effective and manageable software development approach.
Agreed, agile development is a good discipline, but too many of the less experienced adopt the process without first understanding that they need very good developers and a well informed and supportive management sponsor; these things create the environment for PM?s to succeed.
Getting the environment around an Agile project right, is not easy but once its OK you reduce your risks and the PM?s stress levels significantly. As a program manager I first understand the business problem we are trying to solve, then I spend time understanding the size, scope, complexity, impact and degree of technical difficulty of the project and communicate this as effectively and as often as I can to management sponsors. I also make sure the project is ?stage gated? and tell management we will be open about technical difficulty and the options open to them but they have the responsibility to focus on the business problem and to stop their business losses if necessary, and the earlier the better.
Once sponsors are fully aware of what they are letting us get into then an Agile project is a matter of leading creative and challenging people and managing business outcome expectations.
Selecting the right PM for the job helps. But I believe that good software development/integration people, who can drive the innovation and problem solving cycles successfully and consistently within an Agile project are worth their weight in gold; we often underestimate the real business value of their contribution. But so are PM?s who can keep sponsor and business user expectations under control whilst solving the business problems as quickly as possible.
Getting the environment around an Agile project right, is not easy but once its OK you reduce your risks and the PM?s stress levels significantly. As a program manager I first understand the business problem we are trying to solve, then I spend time understanding the size, scope, complexity, impact and degree of technical difficulty of the project and communicate this as effectively and as often as I can to management sponsors. I also make sure the project is ?stage gated? and tell management we will be open about technical difficulty and the options open to them but they have the responsibility to focus on the business problem and to stop their business losses if necessary, and the earlier the better.
Once sponsors are fully aware of what they are letting us get into then an Agile project is a matter of leading creative and challenging people and managing business outcome expectations.
Selecting the right PM for the job helps. But I believe that good software development/integration people, who can drive the innovation and problem solving cycles successfully and consistently within an Agile project are worth their weight in gold; we often underestimate the real business value of their contribution. But so are PM?s who can keep sponsor and business user expectations under control whilst solving the business problems as quickly as possible.
Agreed, agile development is a good discipline, but too many of the less experienced adopt the process without first understanding that they need very good developers and a well informed and supportive management sponsor; these things create the environment for PM?s to succeed.
Getting the environment around an Agile project right, is not easy but once its OK you reduce your risks and the PM?s stress levels significantly. As a program manager I first understand the business problem we are trying to solve, then I spend time understanding the size, scope, complexity, impact and degree of technical difficulty of the project and communicate this as effectively and as often as I can to management sponsors. I also make sure the project is ?stage gated? and tell management we will be open about technical difficulty and the options open to them but they have the responsibility to focus on the business problem and to stop their business losses if necessary, and the earlier the better.
Once sponsors are fully aware of what they are letting us get into then an Agile project is a matter of leading creative and challenging people and managing business outcome expectations.
Selecting the right PM for the job helps. But I believe that good software development/integration people, who can drive the innovation and problem solving cycles successfully and consistently within an Agile project are worth their weight in gold; we often underestimate the real business value of their contribution. But so are PM?s who can keep sponsor and business user expectations under control whilst solving the business problems as quickly as possible.
Getting the environment around an Agile project right, is not easy but once its OK you reduce your risks and the PM?s stress levels significantly. As a program manager I first understand the business problem we are trying to solve, then I spend time understanding the size, scope, complexity, impact and degree of technical difficulty of the project and communicate this as effectively and as often as I can to management sponsors. I also make sure the project is ?stage gated? and tell management we will be open about technical difficulty and the options open to them but they have the responsibility to focus on the business problem and to stop their business losses if necessary, and the earlier the better.
Once sponsors are fully aware of what they are letting us get into then an Agile project is a matter of leading creative and challenging people and managing business outcome expectations.
Selecting the right PM for the job helps. But I believe that good software development/integration people, who can drive the innovation and problem solving cycles successfully and consistently within an Agile project are worth their weight in gold; we often underestimate the real business value of their contribution. But so are PM?s who can keep sponsor and business user expectations under control whilst solving the business problems as quickly as possible.
It is all good and well to empower a team of developers but so many companies are turning to agile without evaluating their problems.
Empowering a team just because a project manager does not know what is involved does not solve problems.
Empowering an under skilled team also does not solve problems and just because you have good developers does not mean they are good at gathering requirements or even design.
I have seen it time and time again the developer is given requirements, designs and builds the solution only to find out what was built was wrong in the intial research phase. So I do believe being closer to the customer helps.
Empowering a team just because a project manager does not know what is involved does not solve problems.
Empowering an under skilled team also does not solve problems and just because you have good developers does not mean they are good at gathering requirements or even design.
I have seen it time and time again the developer is given requirements, designs and builds the solution only to find out what was built was wrong in the intial research phase. So I do believe being closer to the customer helps.
Project Monitor is a french tool for project management that I know well. The software is published by the company Virage Group. English is supported by this software very well. More information on http://www.viragegroup.com.
This is a complete solution to manage projects by milestone, workpackages, tasks, budgets allowed, ressource activities, from reporting to consolidated information of sets of projects
This is a complete solution to manage projects by milestone, workpackages, tasks, budgets allowed, ressource activities, from reporting to consolidated information of sets of projects
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
