There's an article at cio magazine titled Lies, Damned Lies and Requirements [cio.com] that has the following comment posted (by Paul, IT Manager, Boston) in response to it.
Having been involved with many large IT projects over the past 20+ years and I've witnessed both great successes and horrible failures. As for the failures sometimes the blame was on the business side for insisting on pie-in-the-sky requirements, but typically more often the blame belongs on the engineering side for under estimating work and overblowing promises. I've learned over the years that the single biggest factor in the success (or failure) of an IT project is the presence (or absence) of a mature, articulate, highly visibile manager over the project lifespan - who has credibility and solid support from management in both camps, and brings an ownership perspective to the daily squabbles that inevitably occur when business expectations are challenged and engineering realities hit home. Its futile to expect self-interested users OR engineering brainiacs to take the long view, when the best chance for success lies in a strong, proactive management approach - the prerequisite FIRST REQUIREMENT.
As Phil Bradley said to me in an e-mail, "...an interesting human factor, that I don't think I have heard articulated before."
It's a very interesting factor indeed. In these times of growing interest in, and adoption of Agility, there are some that are saying that a project manager merely forms a team and then should "get the hell out of the way." I discussed this with Jim Highsmith recently while we were doing some conferences together and we stated "so that's saying a project manager adds no value. We disagree."
So, what value do you think a project manager adds?
Jeff
Firstly, in my experience its
Firstly, in my experience its true. Although I would add, that often the role of the PM described is played by a small group of 2 or more people who have a more-or-less common understanding, and work towards shared goals. But arguably engineering such a group is the PMs work.
Secondly, this comes back to several threads I have been posting in at the agilemodeling newsgroup.
Software development is not a well understood problem, and the 'standard' approaches don't work very well. So a good PM with a deep understanding of both the business and technology sides is needed to resolve the inevitable hard problems that arise. Failure to resolve these problems leads to disaster.
On to agile. I maintain the intractable problem in software development is changing scope. Not as commonly believed changing requirements.
Agile (well at least XP and SCRUM) 'solves' this problem by completing ignoring it. In an XP/SCRUM project scope can change without restriction. In reality what is happening is that they have not solved the scope problem, but they have merely pushed it back onto the client.
At this point one of my software development maxims comes to mind.
Client: When will my system be finished?
Developer: When you run out of money!
I am sure an XP or SCRUM person would response that the development is always complete at the end of every iteration, because there is a working system. This embeds an assumption that a system of arbitrary scope can always be deployed. If you are talking about a website, then its probably true. If you are talking about any kind of core business application, its certainly not true.
Note that FDD and DSDM try to control scope. In FDD the first 3 processes are substantially a scoping exercise. DSDM takes a different approach and as I recall favors prototypes to define scope.
phil
In my Exprience Its
Hi all,
I must admit that I failed once in a project as a Project Manager (about 6 years ago). At least for three months, I was certain the client was to blame (he simply did'nt quit knew what he wanted, but that was natural as it was a learning process for him too). Anyway I got hurt but I managed to recover from it well. I've learned that a Project Manager as to take ownership and this means to make use of his Iron fist for the sake of sucessfull management and requirements if needed, this not meaning that he shouldn't flexible and take into account change in the specifics.
The basic problem that I've faced was the fact that I felt pushed to keep pace of my Director/Sales promises and clients expectations (I looked at him always). Most client/supplier meetings were with this Director, me, the client and other experts (Document Management, Data Quality, Workflow, e-Business/Web/Portals) and almost always resulted in speculation and a brainstorm of different ideas increasing the scope creep. I was not brave enough to say, NO NO NO NO. I'm out if this proceeds, or we decide here right now about what we really want for start or I'm out (ha about that way of doing things, forget it as you want this done in 3 months, otherwise you came here and sit at my seat).
In age I was the youngest (25) of them all inspite of the fact thay all respected what I had to say and my former achievements, just didn't said enough and got lost, in a position where my reponsibility was to guide others rather then be lost. So I was responsible for the failure, absolutely.
So my advice to young project managers is, although you should always try in your heart to please the client and whoever is on the top of the food chain, if something looks fishy it is fishy, so negotiate truthfully (not hiding anything from whoever is concerned), if everything fails use your Iron fist. They will respect you more during the project and even more when project ends as it will end well, meanwhile use the force if needed, and better sooner then later.
So I fully concur with Pauls response to the article. Specially when he states:
"...and brings an ownership perspective to the daily squabbles that inevitably occur when business expectations are challenged and engineering realities hit home"
I would add, it is the reponsibility of the PM to challenge business expectations no matter who created them and challenge engeneering realities, right at the start.
So in the end is all about managing people and communication. Methodology is important, but its is not a silver bullet, with SCRUM, DSDM or FDD.
This are things that can't be defined in a process.
Nuno Lopes
PS: When interviewing a new member I always ask, do you have already failed in your task? If so why and what was the solution?
Nuno Lopes
Value of the Project Manager
I have seen a number of project managers that have been little value to the project. As a generalisation these are the PMs that think they are managing the project by creating a gantt chart, assigning ownership of the tasks and producing periodic status reports.
Some activities that I believe a PM has added value to the project.
Creation and execution of a project communication plan. This invloves identifying who in the organisation and elsewhere could exert influence over the project, and developing how and when that project will be communicated and by whom.
Actively Managing the Project Risks, and these are all risks business and technical which could affect the successful achivement of the business objectives.
Project Scope Management. A good PM can add value by knowing how much the scope can change without impacting cost and schedule. Mind you the majority seem to have the view that any change increases costs and schedules.
Manging the Human Resources both intra-team and inter-team dynamics.A good PM is most likely to set the personal dynamics of the project.
Stakeholder Management. Someone needs to act as the "trusted advisor" between those engrossed in building a solution and those expecting results and paying out the $$$$. I was previously doubtful of the value of this, until I worked on a project when the Stakeholder insisted in goint to anyone directly....we ended up with n different Number 1 project priorities. Stakeholders describe the vision, the PM puts structure around the vision.
The PM focuses on ensuring the solution delivers the benefits. It is beyond managing a software development process.
Phil wrote
So a good PM with a deep understanding of both the business and technology sides is needed to resolve the inevitable hard problems that arise.
I've been involved with many good PMs who dont have deep understanding of technology. Phil, Why should they need to have a good understanding ? Surely the role of the solution architect is to fullfil that expertise role, the PM leverages of trusted expertise by either business representative or technoloists with enough savvy to test either side. If the PM is focusing on the technology knowledge then I would argues they are not managing the project.
The exception being where it is a small team with a limited scope, in which case the PM side is less important.
Responsability & Value of a PM
Hi David,
"I have seen a number of project managers that have been little value to the project. ...."
In the end, who is accountable for the successfull delivery of the project? If the PM isn't then IMHO his/her value is next to nil, in other words I might just hire an high profile administrative person on his/her place working as a shield if projects go bad. The less the administrative person knows about anything important for the success of the project the better, its a sitting duck :)~
Yes, they should be able to manage and "control" multiple stakeholders interests, and give them structure. As for technology, I believe that a good PM if needed should be able to sit next to the system architect and tackle a few lines of code. This is the same as seeing a large ship fleet owner getting his ands dirty repairing a ship, moving the teams forward, giving them confidence. I've met some PM that are full of blablabla and very little action, in the end what it means is that they don't actually control the project, neither can steer it.
Nuno Lopes
In the end, who is accountabl
In the end, who is accountable for the successfull delivery of the project? If the PM isn't then IMHO his/her value is next to nil,..
Nuno,
I think you are attributing too much power and responsibility to a PM to unitlaterally hold the PM accountable. For example a project is stopped mid flight due to re-priotisation in the business.
Yes, they should be able to manage and "control" multiple stakeholders interests, and give them structure.
My thoughts are more firm...they must do this.
I am suprised with the significant % of Projects I have come across without an active communications plan. Some PM's think a status update is sufficient. One area of FDD that I really find beneficial are the reports.
As for technology, I believe that a good PM if needed should be able to sit next to the system architect and tackle a few lines of code. This is the same as seeing a large ship fleet owner getting his ands dirty repairing a ship, moving the teams forward, giving them confidence.
I would encourage you to consider your analogy from the passengers viewpont. If they saw the Captain or Owner of a ship getting his hands dirty, I think the passengers would be more alarmed then reassured.
Perhaps our disagrement is based on size of project. The role you described would typically be filled by a team leader (or in FDD a Chief Programmer) From a recent project we had 8 teams of which 5 were technology staffed and needed to handle the following technologies:
No way the PM would be able to get coding level issues across all that technology, and in my opinion if he did need to then the team leaders and architects are not doing their job.
In the end, who is accountable
Hi,
My intent was not to say that a PM is blindly accountable for any failures. As you have said is essential for a PM to steam up an active communication plan sustained by good reporting artifacts. This communication plan needs to be good enough to spot ineficiencies, dificulties and problems during project development so it can be steared accordingly without being to heavy on the develpment team. Without this he is for sure a sitting duck that should be hold accountable for any project failure. The reason why is simple, he/she is is not managing the project but simply distibuting assignements.
The two failing projects that I've witnessed the problem was not technical but of management (one of them my own).
"I would encourage you to consider your analogy from the passengers viewpont. If they saw the Captain or Owner of a ship getting his hands dirty, I think the passengers would be more alarmed then reassured."
Probably yes, it depends how the PM is viewed by the customer. I see it wee bit like "Bill Gates mingling with developers" as it was reported that it was his practice. I think this excellent!
"No way the PM would be able to get coding level issues across all that technology, and in my opinion if he did need to then the team leaders and architects are not doing their job."
Again I'm not stating the the PM needs to be knowledgeble in all technologies. What I don't think is that a "clean" (PM that avoids at all costs to get his ends dirty) PM is able to stear technical issues with the support of the CP or CA if he is not prepared to lead by example.
"Perhaps our disagrement is based on size of project."
I don't think so.
"The role you described would typically be filled by a team leader (or in FDD a Chief Programmer)"
No it is not. IMHO, a good PM needs have knowledge of everything (not necessarly to be efficient on everything), this not to act as substitute of a CP or a CA, or Domain Modeller, but to understand and evaluate reports from a technical prespective. To understand the problems of the CP, the CA or any other team member and be prepared to lead by example. This is what I call Active Management.
Nuno Lopes
PS: I don't know COBOL, but I can understand a COBOL program.
Where does significant value in a PM come from ?
Nuno wrote,
No it is not. IMHO, a good PM needs have knowledge of everything (not necessarly to be efficient on everything), this not to act as substitute of a CP or a CA, or Domain Modeller, but to understand and evaluate reports from a technical prespective. To understand the problems of the CP, the CA or any other team member and be prepared to lead by example. This is what I call Active Management.
I haven't sat my PMI Certification yet, but I dont remember it placing an emphasis on the PM needing to have knowledge of everything.
BTW In the consulting area we are seeing an increasing trend of clients only accepting PMs who are certified, which is why I need to sit the certification exam....scary thought!. Here are the Knowledge Areas of PM, as defined by the Project Management Institute:
I don't see a logical place under these knowledge areas for the technical activities you've defined, where would you see it fitting ?
Which leads me to the conclusion based on your view that significant value from a PM comes from an activities beyond this charter. Which
is an interesting observation if right, I need to think about this some more.
David
"BTW In the consulting area w
"BTW In the consulting area we are seeing an increasing trend of clients only accepting PMs who are certified, which is why I need to sit the certification exam....scary thought!"
I think this is excellent!
"I don't see a logical place under these knowledge areas for the technical activities you've defined, where would you see it fitting ?"
IMHO a Certified Project Manager does not make it a good one in the software business, nevertheless is a garantee of quality when one can't evaluate anything else. I can take any of the desciplines enumerated and fit it on any field. Would you employ a leading Project Manager in the Shoes Industry to manage a software project when you have a leading Project Manager in the Software Industry? Probably you would, I would not. So there is a lot of data missing on the list you have just posted. Is this data relevant, I think so.
So what is the differentiator in terms of skills beween a PM managing software projects and any other PM?
Nuno Lopes
A PM is a PM regardless of the industry
The basic skills of project management are the same. If you have a look at the list of knowledge areas for a PM as defined by the PMI, you'll see that they apply to pretty much any industry. A PM in the construction or engineering industries also needs to think about scope, time, cost, quality, human resources, risk...etc.
A few years ago I hired an engineer who wanted to make a career change into software development. I gave him a position as a trainee developer. It wasn't long before his skills improved as a developer, but the real value that he brought to the development team was what he learnt as a project manager on civil engineering projects. His level of discipline and professionalism as a project manager put our software project managers to shame. What he was able to contribute in terms of just basic good project management principles, making sure you knew what you were doing before you started, was significant.
The difference between project managers from different industries is their level of understanding of that particular domain. Knowing how to code will help in managing software development but it's not essential. I was put onto a project with an extremely complex domain that I didn't understand and a language that I'd never written in (java) but it didn't matter. The issues on the project weren't to do with the complexity of the domain or the language being used, it was all to do with communication and expectations.
People are people, most of project management is managing people so the basic skills are the same regardless of the industry.
Martin Bauer
Technical Director
http://www.designit.com.au
Shoe PMs ?
Would you employ a leading Project Manager in the Shoes Industry to manage a software project when you have a leading Project Manager in the Software Industry? Probably you would, I would not.
Nuno,
I dont know what put this in your mind, and it certainly an incorrect statement of my point of view. All the shoe PMs I know would be way overqualified for the software industry - just think of how they continuously delvier products on time, to budget and with a high degree of quality :)
Reread the list of knowledge areas ! Don't you think Scope Management may in anyway play a role in a PM needing to understand the problem domain ? Do you think Risk Management could be aided by having an understanding of the problem domain ?
Where I believe we are in direct conflict of opinion is I my reading of of your comments, is you believe the best value a PM can provide is managing "down" the project, where I would view the best value comes in a PM managing "up" the project. The behaviour and activities you describe I would classify as expected and valued in a Team Leader, however I dont believe they have significant value in a PM.
Perhaps you could illustrate some experiences on how the PM managing down has added significant business value to a project.
David
Shoe PMs ?
Ok, different people share different experiences. I believe in horizontal (not "up" or "down") Management (sometimes up sometimes down) when it comes to software project management (this does not mean anarchy or lack of roles and assignment of responsibilities)
"I would classify as expected and valued in a Team Leader, however I dont believe they have significant value in a PM."
I don't think that size matters when it comes to a good a PM. So basically I believe any good PM needs to be good either in a team sized project or on a project spanning multiple teams. I understand that the more people you have in the playing field the attributes that you find very usefull (so do I) are more and more relevevant.
I did not mean that a good PM on some field can't become or even be better then a PM experienced in the sofware development. But I must say that I've never found one, so I don't know if this is the norm.
Also I think the idea of a certification in PM is excellent as at least in Portugal there a lack of formal/practical education on that area of knowledge.
Nuno Lopes
PS: What I do argue is that technical knowledge is not irrelevant to a good PM but again this is IMHO.
We agree !
Ok, different people share different experiences. I believe in horizontal (not "up" or "down") Management (sometimes up sometimes down) when it comes to software project management
Can you share more information about Horizontal Management ?
"I would classify as expected and valued in a Team Leader, however I dont believe they have significant value in a PM."
I don't think that size matters when it comes to a good a PM.
I didnt mention size here, its about skill sets, responsibilities, accountabilities.
PS: What I do argue is that technical knowledge is not irrelevant to a good PM but again this is IMHO.
We agree on this !! I've not argued that technical knowledge is irrelevant.
David
P.S. Again I would like your examples of how this technical knowledge in the PM delivers signicant value to the project.
Yes I do think we agree on most aspects!
"I didnt mention size here, its about skill sets, responsibilities, accountabilities."
Well, my reasoning is the following. In small projects where you have as little as 3-6 people the team leader actually becomes the Project Manager. This pattern is quite common in today fast pace technological environment. In projects having multiple teams, then the role of the project manager is quite often decoupled from the team leader as it should be.
"Again I would like your examples of how this technical knowledge in the PM delivers signicant value to the project."
ENGAGEMENT!! I believe in leadership my example. A PM of projects of any size also function as a bridge between business objectives and technical resources and constraints. This is relevant when solving daily squables and when keeping project focus and delivery on time. A PM with skill sets both in business and in IT can better work as a bridge, steaming engagment from both parties. To this he/she must be able to sit down at talk and act at any level in order to delegate and stear confidence (manage expectations).
Myself when teams are getting tired or losing focus I often sit down with them, discuss problems and propose solutions. Sometimes I even provide an example to Team Leader or SA, but again its their decision. Wether they opt for my proposal or not they see that management is not only making meetings, producing reports and distributing assignments with the collaboration or not of the Chief Programmers. If project/features schedules are made with strong envolvment of CP and CA (as proposed by FDD), they know that management can act proactivly on their side to solve unexpected problems. We can delegate, but delegation IMHO is not only about distributing assignements based on some time constraints and complementing skill sets (Resource/Risk), as it needs to be enforced along the project IMHO by the PM with actions visible by any member of the project (Visibility).
Nuno Lopes
Horizontal MGMT
"Can you share more information about Horizontal Management ?"
Ok, "Horizontal MGMT" is a term that crossed my as I don't think that only managing "up" or managing "down" the project really works (at least in my experience).
The problem that I face with Managing "down" the project is of cascade delegation. When a project faces a "problem" and people being are pressured to deliver results managing down might not work that well when you need results fast.
The problem that I face with Managing "up" the project is that is not feasable for the PM for long periods of time (more the 1 or two days) as the PM might turn to be a bottleneck.
So what I mean by horizontal managament is there is no "fixed" strategy to manage the project. Also I mean that there must not exist more then 2 layers of communication (PM communicates with Chief Architects and Chief Programmers and other key persons). Then they communicate with whoever is concerned. Now the CA may come with a problem or you noticed that the a CP is unconfortable about some decision, or some critical feature is late, then you need to understand why and probably participate in a meeting with the CP with the programmers for the sake of steaming up Engagement.
There might be a new feature that may require some "heavy lifting". The CA or CP says it is "impossible" to deliver it, and you need to understand how they have perceived this new feature within the scope of the project and what are the solutions being discussed.
Nuno Lopes
Deep understanding of technology
Hi David,
This comes back to my contention that software development is not a well understood process (human activity). Although Martin's comments are well taken - project management is in general not done in software development as well as in other disciplines.
My point about a project manager needing deep technical understanding was becuase we encounter far more suprises than bridge builders for example. That is, detecting and solving unanticipated problems is far more important for software project managers. And frequently failing to detect is the real problem.
In my experience, and I am confident this is a general rule (and very prevalent), developers try and implement technology solutions at a low level for problems which really should be solved at a higher level and specifically because the problems are business relevant. Data semantics is a good example, and I am sure you recall UOB's 'Common Customer Project' and the myriad problems of this type encountered.
So the PM (as the interface between SD and the business) needs to understand technical issues and both be able to decide if they have a business component, and if so communicate them to the business in a comprehensible way, such that the business can make an appropriate decision, and of course communicate the decision back to software development and ensure succesful execution.
phil
Where are the real problems?
Hi Phil,
I agree that software development is not a well understood process. It is essentially a human activity often based on documentation that is open to interpretation. However, I'm not sure I agree that software developers encounter more surprises that bridge builders. Well, let me qualify that, if software developers encounter more suprises than bridge builders, is it because software development is a more complex task or that bridge builders have prepared themselves better before construction starts?
In my view, one of the major problems with software development is interpretation. Projects start with an idea or a need, this gets translated into requirements then into a specification and finally into screens and working code. The chances of misinterpretation in any of these steps is where problems occur. Having a business analyst interpret the needs or desires of the business and then having a developer interpret what the business analyst has documented. It's no wonder we run into problems. This is probably why bridge building seems easier, it's harder to misinterpret what bridge is supposed to do!
The question is whether a project manager with technical knowledge is able to minimise the risks inherent in software development. Quite possibly, technical knowledge will help the PM to understand the details and nature of the problems that occur which could lead to resolving these issues better. But does a technical understanding help with understanding and interpreting the client's needs which are far from technical? Is a PM with technical knowledge more likely to be able to deliver on time and on budget? Maybe, maybe not, depends where the problems occur, from my experience, the greatest problems on projects are to do with people not code.
Martin Bauer
Technical Director
http://www.designit.com.au
We agree,,, or maybe not!
"Maybe, maybe not, depends where the problems occur, from my experience, the greatest problems on projects are to do with people not code."
Precisly. Becouse one does not where occur the PM needs to be qualified to sit down with people (any project member, customer or develoment members) and talk something that makes sense to them within the scope of their work.
When building a bridge a PM is quite often delegated to an administrative task (Resource Management/Buy and Task Assignement). How could he know that first do this, then that, then that, if he does not understand a thing about building bridges, neither the client most probably (usually this is delegated to specialists). So client/supplier interaction is less intense in this cases (but the scope never changes or the delimiters are not so fuzzy).
Now when it comes to software development there is far more interaction between client and suppliers, having a deeper impact on development process.
I think complexities between Bridge Making and Software Making are not to be compared. Why? Becouse a Bridge is an immutable asset, so are shoes, and other kinds of products. This not meaning that they are less complex to be developed or less complex to manage the concerning projects.
Whe have been learning all this along the years as software development methodologies that basically were based on "traditional" product development are being abandoned or re-designed (look at XP, FDD and other Agile methods).
"But does a technical understanding help with understanding and interpreting the client's needs which are far from technical?"
I think this is not the case. The case is of understanding both types od problems both in business and technical, so he can manage both better.
Nuno
Have we abandoned
Whe have been learning all this along the years as software development methodologies that basically were based on "traditional" product development are being abandoned or re-designed (look at XP, FDD and other Agile methods).
I am obviously out of the know. I did't think the world had abandoned "traditional" for "agile". Are there stats or facts that would support this claim ? This is a serious question, I have some input into our processes and while I've been promoting Agile for some areas I wouldnt say I've been a roaring sucess. If there is some industry information that supports if you are not doing Agile you are in the minority I would really like to get a reference to it.
I have seen very few Agile projects in the last 2 years. We've seen a signigficant increase in RFP/RFTs mandating RUP.
.
David
RUP can be Agile too!
Hi David,
You might be interested in this paper from OOPSLA about making RUP Agile- if that isn't seen as too heretical...
"Making RUP Agile", Michael Hirsch
OOPSLA 2002 Practitioners Reports, Seattle, Washington, ACM Press, 2002 (ACM DL)
Abstract:
The Unified Development Process (USDP) and especially its implementation by Rational Software Corporation, the Rational Unified Process (RUP), is a comprehensive process covering almost all aspects of software development projects. However, due to the great level of detail provided by RUP, many professionals do not consider RUP practical for small, fast paced projects. This paper reports the experiences with RUP on two small projects with teams of 3 to 5 developers. RUP proved to be adaptable to the needs of small projects and was very effective in both projects. One key to the successful application of RUP in small projects is the careful selection of a proper subset of artifacts and keeping these artifacts very concise and free from unnecessary formalism. This paper goes into the details of what it takes to make RUP agile, how it was applied in the two projects, and how it was configured. Also covered is what elements of RUP contributed to the success of one project, and why RUP could not prevent that the outcome of the other project was less than optimal.
:: Gavin Baker - http://antonym.org/
Can you buikd a bridge ?
G'day Phil,
My point about a project manager needing deep technical understanding was becuase we encounter far more suprises than bridge builders for example. That is, detecting and solving unanticipated problems is far more important for software project managers. And frequently failing to detect is the real problem.
Are you sure your comparison to Bridge Building is accurate ? Or are you just measuring based on the outcomes ? Do you have any indea what issues builders face ? I would think issues of dealing with Unions, environment concerns , government political concerns are serious and complex issues that dont confront many projects that have signigicant software investment ???
Where I disagree with you and Nuno, is this technical problem determination is done by Team Leaders and Technical Architects. As a Team Lead and/or Technical Architect it is my responsibility to do this and communicate it to a PM, with a synopis of the problem, impact, options, recommendation (hopefully). Both you and Nuno seems to have a view the project is building software. But in my experience, in most cases that is not the project. Its about delivering business value.
So the PM (as the interface between SD and the business) needs to understand technical issues.....
I agree understanding the technical problem at high level is required. Again I would suggest that if the PM is "adding value" by technical problem determination, then that is symptomatic of a project with problems. When I talk PM I am refering to the role, if the project has a small scope and/or team size then a single person can fullfil multiple roles.
David
I build software solutions!
Hi David,
"But in my experience, in most cases that is not the project. Its about delivering business value."
I don't know what you mean by business value as it is a concept as fuzzy as quality etc, etc. IMHO the end of a software project is to deliver a software that works according to the needs of the user/clients. A Project Manager that focus on more then this ...... (too new age/marketing, business value blabla, I want to do software that works).
"I would suggest that if the PM is "adding value" by technical problem determination, then that is symptomatic of a project with problems"
If there was not a risk for a Project to suffer from problems there was no need for a PM. I could write:
"I would suggest that if the PM is "adding value" by analysis problem determination, then that is symptomatic of a project with problems"
"I would suggest that if the PM is "adding value" by modeling problem determination, then that is symptomatic of a project with problems"
"I would suggest that if the PM is "adding value" by business problem determination, then that is symptomatic of a project with problems"
"I would suggest that if the PM is "adding value" by communication problem determination, then that is symptomatic of a project with problems"
"I would suggest that if the PM is "adding value" by resource problem determination, then that is symptomatic of a project with problems"
"I would suggest that if the PM is "adding value" by resource problem determination, then that is symptomatic of a project with problems"
The point is, problems can come from anywhere, and a good PM needs to know how to tackle them, one way or another, and not simply delegate the problem to be solved by someone else.
Nuno Lopes
I build business solutions
Hi Nuno,
Hi David,
I don't know what you mean by business value as it is a concept as fuzzy as quality etc, etc.
If you dont know what the business value of the project is, how can you manage it ! Putting up the business objectives of the project is one of the early tasks that is done with stakeholder management. It is the critical step of what I call "feasibility analysis". Based on business summary objectives the feasibility analysis defines the solution, validates the costs and validates the benefits. (Down to the level of "If I give you capability "A" what will it do for your business..how much benefit are you prepared to commit to ? "
IMHO the end of a software project is to deliver a software that works according to the needs of the user/clients.
Again thats where my opinion/approaches differs to you and Phil Bradley. Delivering software that meets the specifications seems to not ensure you get expected the business objectives.
Yes I agree with the rest...IMNSHO a PM facilitates problem resolution. There is a difference between delegation and empowering the project team members. What you describe to me looks like the lack of ability to delegate, overly centralised control ....I have this problem. It will keep the PM busy...infact in these cases I've seen the PM become the bottleneck, because they want to be part of every problem resolution process rather than managing the process.
David
"I build business solutions"?
"Again thats where my opinion/approaches differs to you and Phil Bradley. Delivering software that meets the specifications seems to not ensure you get expected the business objectives."
I agree with you tottally but this is not the same as:
"IMHO the end of a software project is to deliver a software that works according to the needs of the user/clients."
as you seam to imply.
"If you dont know what the business value of the project is, how can you manage it !"
I have said that business value is a fuzzy concept. It is not the same as not reconigizing the business value within the scope of a project. What I've learned with the dot compost era is that business value should not be driven by technology or a project, but definitly technology is a component within the strategy to "deliver/reach" the end business value.
"I build business solutions"
What does this mean? This is software development/project management discussion, not a business management discussion. If you build business solutions than are you a VC? Some investor, do you have a team of experts on investement and busines management, hr management? Anyway if you are then yes we build different things.
Maybe I'm too retro, but one of the things that I got from the dot compost era is that IT consultants (I'm a consultant) whoever role they are don't build/deliver business solutions at most they deliver technological solutions.
Nuno
Delegation.
Hi,
"What you describe to me looks like the lack of ability to delegate"
From where have goten this idea? I've said that is important for a PM to be knowlegeble of everythig (not necessarly efficient on everything), in order ot ve able to sit down with any member of the project and talk something that makes sense to him/she. This does not mean that he does this on every single project to evry single member, only when necessary (it often happens here that Team Members etc etc, are handle their stuff very well).
Nuno
"I build business solutions"?
"Again thats where my opinion/approaches differs to you and Phil Bradley. Delivering software that meets the specifications seems to not ensure you get expected the business objectives."
I agree with you tottally but this is not the same as:
"IMHO the end of a software project is to deliver a software that works according to the needs of the user/clients."
as you seam to imply.
"If you dont know what the business value of the project is, how can you manage it !"
I have said that business value is a fuzzy concept. It is not the same as not reconigizing the business value within the scope of a project. What I've learned with the dot compost era is that business value should not be driven by technology or a project, but definitly technology is a component within the strategy to "deliver/reach" the end business value.
"I build business solutions"
What does this mean? This is software development/project management discussion, not a business management discussion. If you build business solutions than are you a VC? Some investor, do you have a team of experts on investement and busines management, hr management? Anyway if you are then yes we build different things.
Maybe I'm too retro, but one of the things that I got from the dot compost erat is that IT consultants (I'm a consultant) whoever they are don't build/deliver business solutions at most they deliver technological solutions.
Nuno
Bridges and Ministers
we encounter far more suprises than bridge builders for example
True indeed. But surely bridge building (and many other civil engineering projects) would be reasonably well suited to a waterfall-style process?
...project management is in general not done in software development as well as in other disciplines.
Sad but true. I wonder if this is due (at least in some part) to the nature of the deliverable? The fact that software is perceived as malleable, ephemeral and fluid... The client's perception is often that software can easily be changed, much more so than if the deliverable were something tangible. The perception of the cost of change (which increases rapidly with each phase) is disproportionate.
So the PM (as the interface between SD and the business) needs to understand technical issues
I have often wondered if our government would be more efficient if the minister for a particular portfolio were an expert in the field. So the treasurer should have an MBA and a Masters in Accounting. The Minister for Environment should have a PhD in Ecology. The Minister for Health should have a Medical background... and so on. If the decision makers were experts, they should make the best decisions, right?
Unfortunately this falls down on a few counts. First, decisions are not always (maybe even rarely) made based on purely technical factors. They are typically a mix of psychology and politics. Second, that Ministers rely on having top-level advisors who are experts in the field, and who give the Minister all the advice they need to make an 'executive decisison', having weighed in all the factors - technical and otherwise.
So while I agree that a PM should have a good appreciation of technology, I think relying on their lieutenants (the Dev manager and the CPs) for technical advice, is more realistic. It is hard enough as it is to find a PM who is good with people, let alone one who can 'talk shop' with the coders.
:: Gavin Baker - http://antonym.org/
Good management makes a world of difference
Software development is a team based activity. Itâs the PMâs role to assemble the team but to think thatâs where the job ends is a big mistake. Making sure the team works together is a vital part of the PMâs role. Itâs like saying a coachâs role is over once the season starts or worse, during the game. Like a coach, a PM should take an active role guiding and leading the team during the project.
Those of us that are lucky to have worked with a good PM knows what a difference it makes. There is clarity and ease about the project that is all too rare in software development. A good project manager makes it possible to achieve more with less effort.
The PM, the person who guides and supports the team has an incredible influence, for good or bad. It doesnât matter what process youâre using, quality leadership and management stands out. To under estimate the impact of the Project Manager will put any project at great risk before itâs even started.
Martin Bauer
Technical Director
http://www.designit.com.au
Project Managers
Some random thoughts for what it is worth:
Over the years I've worked for a number of project managers and been fortunate that most of them have been quite good. All have been different. All have had different strengths and weaknesses. All have been human.
Most of them have been project managers that I could trust and respect, that did not use me as a pawn in some political game with stakeholders or clients, that challenged me to achieve more but did not expect the ridiculous, that knew I am human, that looked after my interests and my career, etc.
For this sort of project manager I was willing to work my butt off to ensure he got the software he wanted, when he wanted it. Strangely these project managers seem to have been quite successful at repeatedly delivering software projects reasonably on time and reasonably within budget.
Some of the project managers I have worked for have had good technical abilities, others have managed Gannt charts, budget spreadsheets and powerpoint presentations better. Few have had much in common with one another. I do think a project needs both administrative and technical leadership and FDD processes talk of a Project Manager, Chief Architect and Development Manager roles. However, the distribution of those three roles/sets of responsibilities between one or more people I think is likely to be different in almost every team because every team's make up is slightly different.
I think many project managers get a bad rap because they are not given the information they need to make informed decisions. It's a little hard to steer something if you do not know where you are, not sure where you are going next and have no clue how fast you are moving. I think many developers are given a bad rap by project managers because they are not given reasonable process tools with which to derive the information that the project managers need to steer the project. One of the reasons I like FDD so much is its ability to generate status and rate of progress info reasonably accurately and easily.
Bottom line: I think software project management is awful job and that the people who do it are either very brave, very naive, or very well paid.
Steve
2 out of 3 *smile*
...the people who do it are either very brave, very naive, or very well paid.
My first cheeky response to this was - "or (d) all of the above." But then I thought for many it would be - "well, two out of three 'aint bad!" Yeah I know... all project managers are very well paid plus one other thing
BTW - Nice post Mr. P.
Jeff
RE: Project Managers
Great post David, we loose sometimes the human aspect of the thing when it comes to the IT technical staff.
"Bottom line: I think software project management is awful job and that the people who do it are either very brave, very naive, or very well paid."
In the failed project that I mentioned I think was "very naive" and "very brave". A very dangerous combination :) Anyway problem solved.
Nuno Lopes
The flip side
Looking at the role of a PM, I can think of a few things a good PM should not do:
All the above is based on past experience; my own and my colleagues.
:: Gavin Baker - http://antonym.org/