Some are burned on previous implimentations that just don't do what they are supposed to do. Your #3 is that about project management software. Going more generally, the company may have put out a new process that was to solve a problem, but made it worse.
Sometimes the new solution has helped management see the business better, but made people at bottom take more steps (introducing more ways things can go wrong). I remember one place I worked where the managers used mice and the admin workers used keyboards for entry. The admin workers felt that they'd never be able to work as quickly and efficiently because they had to do several fancy mouse movements instead of a few key presses.
Discussion on:
View:
Show:
In most of the Indian companies, one most important reason to fail any project is the breaking up Hierarchy.
Lack of commitment from the organisation towards PM shows itself pretty commonly, all the others are to lesser or greater extents subsets of that. As the PM, it's part of the role to educate the organisation into committing itself; no mean feat at times.
Talking of lack of commitment, we get only 1 PM article on here every couple of weeks, many of them are pretty lame too, and this one's a repeat. The cheek...
Talking of lack of commitment, we get only 1 PM article on here every couple of weeks, many of them are pretty lame too, and this one's a repeat. The cheek...
I wouldn't say that #2 says it all but it's certainly a project killer. Many years ago I was given a major, understaffed, and ill defined project and as a team we agreed that before we jumped in feet first we had to clearly define what the project was supposed to accomplish and develop a plan. After a few weeks we'd made quite a bit of progress. We had wall charts, documented analysis, initial estimates, progress reports... Then our sponsoring exec read us the riot act saying (obscenties deleted) I haven't seen you guys do anything but draw pictures. Get to work and cut some code. It was nearly a career killer. I survived only by delegating and moving on to other things as the project struggled along for several years and died a slow, agonizing death. Of course today our execs are much more enlightened. Right?
Sadly, some execs seem to think that project management is a cure-all which just involves giving an overburdened junior line manager a copy of MS Project (without training, of course). Presumably these execs like to learn the hard way. However, it does leave open the question of how to convince execs otherwise, perhaps us PMs should learn more about a sales techniques.
Not sure that many of the execs taking the approach mentioned by tim_uk actually learn. In my experience, many seem to conclude that the failure was not their approach, they just gave the assignment to the wrong person (again and again and again.......). Talk about the insanity of doing the same thing over and over again assuming you will get a different result.
Sometimes the PM becomes too detailed in the tasks included. We had a project that ended up with over 10,000 tasks, and it was impossible to make time to just update your progression. Almost felt like I had to write down when I went to the bathroom!!
I learned my PM skills in a business that would track every task on a project of ?60m down to the half-our (including every half-hour task, and each and every task had it's own cost account). We had a small team of three managing the updates and an automnated process that linked the tasks the resources and the budgets. one PM, an assistant PM to cover the scale of meetins and coordination and one guy planning. If you need it, you have to staff for that too, if you don't need the detail don't plan it. You don't need to see every step of a serial activity, provided you can reflect a robust and realistic view of percentage complete along this path.
I think also that very often the project manager and all the people involved in a new project do not put in their planning the necessary time to work on the project.
It is a big mistake to believe a new project can be driven by people who are also dealing with their normal day to day work. The day to day will occupy the whole space and project management will be shortly reduced to zero driving directectly to a project failure.
It is a big mistake to believe a new project can be driven by people who are also dealing with their normal day to day work. The day to day will occupy the whole space and project management will be shortly reduced to zero driving directectly to a project failure.
You almost sound like PM is not normnal day-to-day (or dare I even say full-time) role.
My experience is if PM and operationsal activities are on the same individual, the operational must-do-now stuff fills almost all the avaialbel time. The PM must-do-now stuff urgent tends to be tied to reporting, the important stuff like risk-reviews, resource evaluation gets second step until an impact issue makes it urgent, by which time it's too late. If you don't have the scale for any project to keep a PM busy full-time, give all the PM functions from differnt projects to one PM who doesn't have operational roles. You will obviously need to separate the resource control to team leaders, but this takes the urgent stuff out the way of the important stuff.
My experience is if PM and operationsal activities are on the same individual, the operational must-do-now stuff fills almost all the avaialbel time. The PM must-do-now stuff urgent tends to be tied to reporting, the important stuff like risk-reviews, resource evaluation gets second step until an impact issue makes it urgent, by which time it's too late. If you don't have the scale for any project to keep a PM busy full-time, give all the PM functions from differnt projects to one PM who doesn't have operational roles. You will obviously need to separate the resource control to team leaders, but this takes the urgent stuff out the way of the important stuff.
...is pointing to the situation where the priorities have not been clearly set and the additional duties are expected to be accomplished in the same framework and priority level as all of their other work. Ponroy is addressing poor resource management and allocation.
(On the side, is anyone seeing these singlesnet ads on this page. Good Lord!)
(On the side, is anyone seeing these singlesnet ads on this page. Good Lord!)
The 5 point list pretty well somes up the key challenges.
Perhaps one dynamic that may have gotten over looked is the dependency that Project Management relies upon getting good time estimation from his/her SME's.
The key here is that the SME's both Developer & Sys Admin may not know how estimtate time. As the PM is dependant upon their judgement a gap may occur between the PM and Sr. Mgt over the schedule which leads back to point #1,#2 and #4.
Perhaps one dynamic that may have gotten over looked is the dependency that Project Management relies upon getting good time estimation from his/her SME's.
The key here is that the SME's both Developer & Sys Admin may not know how estimtate time. As the PM is dependant upon their judgement a gap may occur between the PM and Sr. Mgt over the schedule which leads back to point #1,#2 and #4.
Some corporations and government departments rely on project management implementations but only for IT solutions; there is no consideration within business or with organization-wide initiatives that project management can provide value, tactically or strategically. All too often, the more credentialed individuals are considered to be specialized and therefore must be an IT person. So many certifications, PMP (Project Management Professional) included are placed into a technology hopper because, like IT, project management practitioners need to focus more on business objectives and not inward at individual projects or IT solutions.
Project managers and their executives need a better "value equation" on how an effective project governance methodology can benefit the bottom line. If your organization has challenges in executing (getting things done) create a business case on how a PM methodology will deliver executive value. If your organization has a challenge in priority management or risk management; create a Portfolio (collection of business projects) scorecard based on project scorecards to identify challenges and risks, identify which projects are connected to the business plan and quickly focus executive energy on the critical few business projects that need their attention.
Only when corporate executives understand the business case of project management, the value that consistent project delivery can provide to their bottom line will inroads of project governance and delivery be made. It is up to the project management profession to consistently focus on what value and improvments they will bring to an organization.
Project managers and their executives need a better "value equation" on how an effective project governance methodology can benefit the bottom line. If your organization has challenges in executing (getting things done) create a business case on how a PM methodology will deliver executive value. If your organization has a challenge in priority management or risk management; create a Portfolio (collection of business projects) scorecard based on project scorecards to identify challenges and risks, identify which projects are connected to the business plan and quickly focus executive energy on the critical few business projects that need their attention.
Only when corporate executives understand the business case of project management, the value that consistent project delivery can provide to their bottom line will inroads of project governance and delivery be made. It is up to the project management profession to consistently focus on what value and improvments they will bring to an organization.
The Answer is it's the infrastructure. Business that doesn't fail is built on infrastructure that doesn't fail. The PM oversees the details to insure the infrastructure will not fail.
Infrastructure that fails results in business losses, downturns, and customers bailing on poor performance.
The time, effort, and funding in the front end equals less time, effort, and funding for maintenance and upgrades.
Hey! you got a two 'fer!
Have a nice day!
Infrastructure that fails results in business losses, downturns, and customers bailing on poor performance.
The time, effort, and funding in the front end equals less time, effort, and funding for maintenance and upgrades.
Hey! you got a two 'fer!
Have a nice day!
Agree with you Lorne - if you want PMgmt to be taken on board seriously by your executives you've got to present it to them in something they understand. The reality is as PM's we practice what we preach every day so it is hard for us to understand why our exec's don't get it - the reality is they don't have to because thats what we do. Our challenge is to present the case for PMgmt to them in a way that the understand. If they can see the value proposition they'll run with it and leave the detail to us.
Scope creep always happens, for management will keep adding things that they want in addition.
As agile software development methodologies have matured and become widely adopted we've found that scope creep is less of a problem. Assume that business needs and scope will change. They will. Assume that you can't plan a software project in excruciating detail up front. In most cases you can't. Agile does not mean unplanned. It means planning to manage change. This is very different from the usual project management approach which includes change management but tries very hard to keep changes out of scope.
Scope creep is inevitable with IT projects BUT the organisations that just want to do it (Nike)and dont plan enough upfront get into big trouble on this issue.
Define the scope upfront, make sure everybody understands what the deliverables/outcomes are. Imagine buiding a car and you don't know what it should look like or what size engine it should have. That is what a lack of scope on a project does.
Define the scope upfront, make sure everybody understands what the deliverables/outcomes are. Imagine buiding a car and you don't know what it should look like or what size engine it should have. That is what a lack of scope on a project does.
is the disease. Scope creep itself, is a natural consequence of attempting to define scope. 
Defining scope is a lot harder to do than to write.
The purchasing system will not integrate with the existing invoicing system, no poblem, clear and unambigious. OK so likely to creep all over that one.
We will collect order data (undefined) and use in ways that will enhance efficiency (no benchmark) as according to our mission statement (pulease).
A continual battle as to what the scope is, was, could be and may be.
Defining scope is a lot harder to do than to write.
The purchasing system will not integrate with the existing invoicing system, no poblem, clear and unambigious. OK so likely to creep all over that one.
We will collect order data (undefined) and use in ways that will enhance efficiency (no benchmark) as according to our mission statement (pulease).
A continual battle as to what the scope is, was, could be and may be.
We all accept that scope creep is hard to define, but the simple explanation if you will forgive me is that it has to be defined or else you will not know if scope crept. We often get poorly defined projects and this area is the worst especially in IT.
Secondly where scope does change, and it will mostly I agree, we do of course use change management to authorise and scope the scope changes.
Secondly where scope does change, and it will mostly I agree, we do of course use change management to authorise and scope the scope changes.
That's the one where what you have to do get's changed. But not the budget, the schedule, the people or any other already costed resources isn't it?
Of course we use...
Sorry but far too often to the tools of project management are only used to modify the plan, the reality usually lags.
Of course we use...
Sorry but far too often to the tools of project management are only used to modify the plan, the reality usually lags.
Or is it scope clarity? My experience has been that we substitute and blame scope creep for our inability, at least in software projects, to completely understand and document every requirement. So, when that clarity emerges as prototypes, wireframes and data models start to develop, we blame the end users. I think Agile's biggest promise is the acknowledgement that requirements and priorities change and need to be accommodated and embraced.
Communication between Project Management Lead and the developers is also essential. The developers need to know that they must follow the detailed plan. If they deviate from it, the product will not be what the user wants. Learning to communicate as a group will also help the PMO office move ahead with the project. Effective listening skills are also needed. If you are not hearing what is being said because you (a developer) are thinking of how to do something when the requirements are being written as the ???what the system should do,??? slows down the development also.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
