Mixing
Should the software architect report to the project manager? [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
6
down vote
favorite
On a software team with a software architect and a project manager, should the architect report to the project manager? Or should the architect report to the project manager's superior?
I have difficulty coming up with pros and cons for both options. The only things I could find were:
- the architect and project manager may hold conflicting opinions (but not which ones), and
- an example where the architect reports to the project manager (but not why).
Since the architect guards quality, and the project manager guards time and budget, there are bound to be conflicts. But how is this best reflected in the reporting hierarchy, and why?
Edit
To clarify my question:
- the question is not company-specific. See @Marv's comment for explanation.
- It's hard to give a short definition of a software architect. To summarize Simon Brown: a software architect is responsible for the technical aspects of the software project, and coaches the team's developers. I do not mean a tech lead, which is a role combining architecture and project management.
- there doesn't seem to be disagreement on what a project manager does.
- the Project Management.SE site does not seem suitable, as it's about project management, not organization of business.
software-industry management team
edited May 23 '17 at 12:37
Community♦
1
asked Nov 6 '15 at 10:51
Frank Kusters
1476
closed as off-topic by Lilienthal♦, Philip Kendall, keshlam, IDrinkandIKnowThings, mcknz Nov 6 '15 at 17:41
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address only a specific company or position are of limited use to future visitors. Questions seeking legal advice should be directed to legal professionals. For more information, click here." – Lilienthal, keshlam, IDrinkandIKnowThings
suggest improvements |Â
up vote
6
down vote
favorite
On a software team with a software architect and a project manager, should the architect report to the project manager? Or should the architect report to the project manager's superior?
I have difficulty coming up with pros and cons for both options. The only things I could find were:
- the architect and project manager may hold conflicting opinions (but not which ones), and
- an example where the architect reports to the project manager (but not why).
Since the architect guards quality, and the project manager guards time and budget, there are bound to be conflicts. But how is this best reflected in the reporting hierarchy, and why?
Edit
To clarify my question:
- the question is not company-specific. See @Marv's comment for explanation.
- It's hard to give a short definition of a software architect. To summarize Simon Brown: a software architect is responsible for the technical aspects of the software project, and coaches the team's developers. I do not mean a tech lead, which is a role combining architecture and project management.
- there doesn't seem to be disagreement on what a project manager does.
- the Project Management.SE site does not seem suitable, as it's about project management, not organization of business.
software-industry management team
edited May 23 '17 at 12:37
Community♦
1
asked Nov 6 '15 at 10:51
Frank Kusters
1476
closed as off-topic by Lilienthal♦, Philip Kendall, keshlam, IDrinkandIKnowThings, mcknz Nov 6 '15 at 17:41
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address only a specific company or position are of limited use to future visitors. Questions seeking legal advice should be directed to legal professionals. For more information, click here." – Lilienthal, keshlam, IDrinkandIKnowThings
3
In my company they are of equal rank and both report upwards. I don't know if this is standard practice or even best practice. In fact my observation is that it seems to breed conflict.
– Dustybin80
Nov 6 '15 at 11:33
1
This seems so dependent on the situation and your definition of the titles involved that I'm not sure there's a useful answer or universal best practice.
– Lilienthal♦
Nov 6 '15 at 12:15
I don't agree a PM does not guard quality.
– paparazzo
Nov 6 '15 at 17:14
1
I think it is completely incorrect that this has been closed as company-specific. There is nothing in the question that is company specific. The roles in question are generic and widespread roles and the hierarchy of roles is both fairly standard and debatable. I propose the OP posts this question on the Project Management SE here (pm.stackexchange.com/questions) where it may be better understood
– Marv Mills
Nov 6 '15 at 18:18
suggest improvements |Â
up vote
6
down vote
favorite
up vote
6
down vote
favorite
On a software team with a software architect and a project manager, should the architect report to the project manager? Or should the architect report to the project manager's superior?
I have difficulty coming up with pros and cons for both options. The only things I could find were:
- the architect and project manager may hold conflicting opinions (but not which ones), and
- an example where the architect reports to the project manager (but not why).
Since the architect guards quality, and the project manager guards time and budget, there are bound to be conflicts. But how is this best reflected in the reporting hierarchy, and why?
Edit
To clarify my question:
- the question is not company-specific. See @Marv's comment for explanation.
- It's hard to give a short definition of a software architect. To summarize Simon Brown: a software architect is responsible for the technical aspects of the software project, and coaches the team's developers. I do not mean a tech lead, which is a role combining architecture and project management.
- there doesn't seem to be disagreement on what a project manager does.
- the Project Management.SE site does not seem suitable, as it's about project management, not organization of business.
software-industry management team
edited May 23 '17 at 12:37
Community♦
1
asked Nov 6 '15 at 10:51
Frank Kusters
1476
On a software team with a software architect and a project manager, should the architect report to the project manager? Or should the architect report to the project manager's superior?
I have difficulty coming up with pros and cons for both options. The only things I could find were:
- the architect and project manager may hold conflicting opinions (but not which ones), and
- an example where the architect reports to the project manager (but not why).
Since the architect guards quality, and the project manager guards time and budget, there are bound to be conflicts. But how is this best reflected in the reporting hierarchy, and why?
Edit
To clarify my question:
- the question is not company-specific. See @Marv's comment for explanation.
- It's hard to give a short definition of a software architect. To summarize Simon Brown: a software architect is responsible for the technical aspects of the software project, and coaches the team's developers. I do not mean a tech lead, which is a role combining architecture and project management.
- there doesn't seem to be disagreement on what a project manager does.
- the Project Management.SE site does not seem suitable, as it's about project management, not organization of business.
software-industry management team
edited May 23 '17 at 12:37
Community♦
1
asked Nov 6 '15 at 10:51
Frank Kusters
1476
edited May 23 '17 at 12:37
Community♦
1
edited May 23 '17 at 12:37
Community♦
1
edited May 23 '17 at 12:37
Community♦
1
1
asked Nov 6 '15 at 10:51
Frank Kusters
1476
asked Nov 6 '15 at 10:51
Frank Kusters
1476
asked Nov 6 '15 at 10:51
Frank Kusters
1476
1476
closed as off-topic by Lilienthal♦, Philip Kendall, keshlam, IDrinkandIKnowThings, mcknz Nov 6 '15 at 17:41
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address only a specific company or position are of limited use to future visitors. Questions seeking legal advice should be directed to legal professionals. For more information, click here." – Lilienthal, keshlam, IDrinkandIKnowThings
closed as off-topic by Lilienthal♦, Philip Kendall, keshlam, IDrinkandIKnowThings, mcknz Nov 6 '15 at 17:41
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address only a specific company or position are of limited use to future visitors. Questions seeking legal advice should be directed to legal professionals. For more information, click here." – Lilienthal, keshlam, IDrinkandIKnowThings
3
In my company they are of equal rank and both report upwards. I don't know if this is standard practice or even best practice. In fact my observation is that it seems to breed conflict.
– Dustybin80
Nov 6 '15 at 11:33
1
This seems so dependent on the situation and your definition of the titles involved that I'm not sure there's a useful answer or universal best practice.
– Lilienthal♦
Nov 6 '15 at 12:15
I don't agree a PM does not guard quality.
– paparazzo
Nov 6 '15 at 17:14
1
I think it is completely incorrect that this has been closed as company-specific. There is nothing in the question that is company specific. The roles in question are generic and widespread roles and the hierarchy of roles is both fairly standard and debatable. I propose the OP posts this question on the Project Management SE here (pm.stackexchange.com/questions) where it may be better understood
– Marv Mills
Nov 6 '15 at 18:18
suggest improvements |Â
3
In my company they are of equal rank and both report upwards. I don't know if this is standard practice or even best practice. In fact my observation is that it seems to breed conflict.
– Dustybin80
Nov 6 '15 at 11:33
1
This seems so dependent on the situation and your definition of the titles involved that I'm not sure there's a useful answer or universal best practice.
– Lilienthal♦
Nov 6 '15 at 12:15
I don't agree a PM does not guard quality.
– paparazzo
Nov 6 '15 at 17:14
1
I think it is completely incorrect that this has been closed as company-specific. There is nothing in the question that is company specific. The roles in question are generic and widespread roles and the hierarchy of roles is both fairly standard and debatable. I propose the OP posts this question on the Project Management SE here (pm.stackexchange.com/questions) where it may be better understood
– Marv Mills
Nov 6 '15 at 18:18
3
3
In my company they are of equal rank and both report upwards. I don't know if this is standard practice or even best practice. In fact my observation is that it seems to breed conflict.
– Dustybin80
Nov 6 '15 at 11:33
In my company they are of equal rank and both report upwards. I don't know if this is standard practice or even best practice. In fact my observation is that it seems to breed conflict.
– Dustybin80
Nov 6 '15 at 11:33
1
1
This seems so dependent on the situation and your definition of the titles involved that I'm not sure there's a useful answer or universal best practice.
– Lilienthal♦
Nov 6 '15 at 12:15
This seems so dependent on the situation and your definition of the titles involved that I'm not sure there's a useful answer or universal best practice.
– Lilienthal♦
Nov 6 '15 at 12:15
I don't agree a PM does not guard quality.
– paparazzo
Nov 6 '15 at 17:14
I don't agree a PM does not guard quality.
– paparazzo
Nov 6 '15 at 17:14
1
1
I think it is completely incorrect that this has been closed as company-specific. There is nothing in the question that is company specific. The roles in question are generic and widespread roles and the hierarchy of roles is both fairly standard and debatable. I propose the OP posts this question on the Project Management SE here (pm.stackexchange.com/questions) where it may be better understood
– Marv Mills
Nov 6 '15 at 18:18
I think it is completely incorrect that this has been closed as company-specific. There is nothing in the question that is company specific. The roles in question are generic and widespread roles and the hierarchy of roles is both fairly standard and debatable. I propose the OP posts this question on the Project Management SE here (pm.stackexchange.com/questions) where it may be better understood
– Marv Mills
Nov 6 '15 at 18:18
suggest improvements |Â
4 Answers
4
active
oldest
votes
up vote
5
down vote
accepted
I believe this is a false dichotomy for the following reasons:
- The Project Manager should not try to enforce their opinions on software architecture, that is not their job. Their job is to manage the process of delivering a "product" against requirements. They do this by coordinating/utilising subject matter experts (e.g. Architects) within the project team to provide the necessary elements. If the PM holds (and attempts to implement) opinions on software architecture then the roles and responsibilities are blurred and it is that blurring that creates the problem. The roles and responsibilities of all project team members, including the PM, should be clearly defined in the Project Initiation Document and be unambiguously understood by all.
- Software Architecture will (presumably) assist in the design stages of a software project and therefore is responsible for producing elements of the deliverable. In that respect their outputs become part of the project deliverables and accordingly come under the supervision of the Project Manager. So for the purposes of the project they are part of the project team notionally managed by the project manager, but that does not mean the project manager can or should override them- that should not be the way project management works (see above)
So to summarise, in my opinion and in an ideal world, the architect "reports" to the PM (or more accurately contributes their expertise to the project the PM is managing), but the PM does not trump their input. I am sure there are many flavours of this arrangement in the real world, with all possible shades along the continuum, but the issue here is purely down to Roles and Responsibilities not being defined clearly and observed by all.
answered Nov 6 '15 at 12:00
Marv Mills
4,3831729
I like the answer but a PM can have an opinion about architecture but they should not dictate architecture. If a PM feels an architecture is putting a project at risk then it is fair to report that as a risk.
– paparazzo
Nov 6 '15 at 17:21
@Frisbee you are correct, of course, I got a bit carried away there. I will amend my answer accordingly
– Marv Mills
Nov 6 '15 at 18:14
suggest improvements |Â
up vote
2
down vote
While I agree with other answers on principle, I rarely experience such a pure and true form of Project Management discipline being practiced in the real corporate world.
It is important to look at where unspoken motivations exist to corrupt the intended motivations of the Project Manager. Yes on principle the Project Manager is responsible for delivering the project on budget and on time. It is important to remember that as the PM is the arbiter of Cost and Time, they are only representing 2 of the 3 core tenets of overall scope of work.
In most organizations, Project Managers are not inherently and naturally incentivized to give proper respect and attention to Quality, leading to the insatiably profound temptation for a PM on a struggling project to sacrifice Quality or influence development decisions to be made that favor Time and Cost at the expense of Quality.
This is the profound reason why Technical Architecture, operating at the high level design and focus on Quality Attributes, is so critically important that they not be bound by the reporting structure of the project in general. If the organization values the Technical Architect and Quality Attributes in software then they will not be held to project constraints and instead operate as a balance check against this. If you were to envision the role of a Technical Architect on an Agile organization they would be working closely with the Product Owner to define software needs and set expectations on high level design.
Would you also argue that the Project Manager should hold the Product Owner to task on defining software needs and scope? Of course not, that would be ridiculous.
The concept is the same. They exist as an important stakeholder in the project and not as a contributing member of the development team.
answered Nov 6 '15 at 17:46
maple_shaft
15.7k75296
suggest improvements |Â
up vote
1
down vote
The Architect should report to the person responsible for managing the development team, typically this would be a development manager, but in smaller shops it could be a general IT manager. The PM should report to the business manager, however often times the PM is assigned to the IT department in which case the PM should report to the person responsible for the IT Business, which in smaller shops could be the same person that manages development.
Those roles are for day to day general management responsibilities(Attendance, performance reviews, work assignments). For project responsibilities the Architect is going to have to report progress, problems, and planning to the PM. If the design proposed does not meet business needs for some reason, like it will take to long to implement, it is the PM's call. Generally if the architect, and the PM cannot find an acceptable solution it would escalate to the higher management levels to make final decisions.
Many times these decisions will mean varying from best practices, or standards that have been put in place to meet business demands. It is the job of the architect to then figure out how to meet the new requirements outside of the practices, and make a plan for how to correct these problems once the time crunch is over. Do not keep fighting a battle that is already lost unless some new serious concern takes place.
tl;dr; It is the job of the architect to attempt to provide the project manager with the design they request inside of the parameters they request.
answered Nov 6 '15 at 16:09
IDrinkandIKnowThings
43.8k1397187
This term Architect is used so loosely in the industry that it is clear everybody will have a different answer because everybody has a different experience with what an Architect should be. My answer takes more of an SEI view of the role of software architecture. In my opinion, what you are calling the architect here sounds more like a Project Technical Lead which I think is an important distinction. There is some overlap though.
– maple_shaft
Nov 6 '15 at 17:49
@maple_shaft - Not really an architect is usually involved in the early design development effort. An architect usually takes his hands off when its time to do the heavy lifting of doing actual work, that's when the (good) tech lead digs in and works the hardest. But I agree everyone has a different opinion on what an architect should do. Devs think they should do more work, pms think they should get their nose out of their project... etc.
– IDrinkandIKnowThings
Nov 6 '15 at 19:53
suggest improvements |Â
up vote
-2
down vote
Assuming you mean reports in the meaning of "works for" (obviously an architect should report progress to a PM if relevant), the simple answer is this:
No delivery team members should be managed by a PM, there is a conflict of interest
The PM's job is to make sure the project is delivered on time and for minimum cost. The delivery team (especially architects as in the example) have a responsibility to deliver a fit-for-purpose design and implementation, and this could well not fit within the PM's plan, and a project requires compromises on both sides to deliver.
Giving one side ultimate authority will create an unassailable situation (been there), where the project is badly compromised to meet time and/or budget. Alternately with PM in tow to architecture you end up with a Duke-Nuke'em Forever situation where nothing ships as it needs to be refined/refactored.
You need technical delivery and project management on opposing sides to challenge each other, by this way a good project lies (although it may not feel like it at the time).
answered Nov 6 '15 at 12:12
The Wandering Dev Manager
29.8k956107
One little pedantic point, I don't see it as the PM's responsibility to deliver the project to "minimum cost". The PM's responsibility is to deliver the project to the agreed cost as driven by the requirements and defined in the project mandate (whatever form that takes). Plus of course there is the third point on the triangle; "quality", i.e. it has to meet requirements. However I am sure I am preaching to the choir on all this :)
– Marv Mills
Nov 6 '15 at 12:30
Well in 20+ years of software projects, agreed cost=happy path cost= minimum cost. And despite what PMs say the third point on the triangle is just out of vision due to the big honking cost one filling their vision. My point is though that you need this conflict, it is a healthy debate on project delivery, and the failures are ones where one side is stronger and tilts the project their way.
– The Wandering Dev Manager
Nov 6 '15 at 12:52
Only 20? N00b then ;) I certainly agree with the "conflict" as a good thing as described here, no argument from me- you need both sides pulling to produce the "right" outcome. But I don't really understand your point about quality being "just out of vision". Anyway, as this isn't a discussion site I guess we'll leave it there.
– Marv Mills
Nov 6 '15 at 12:56
I'm sure all have been on projects where cost prioritisation has built a unmaintainable failure. I've also been on the other side. Once spent 18 months with a public sector team, technical but no PM. Kept fitting in what the customer wanted (medical), plus work on code. In version 10 when I arrived, and had never gone live in production, only invited beta (4 years of a team of 8). It never went live, was eventually scrapped when another part of the system was refactored and the need for it went away.
– The Wandering Dev Manager
Nov 6 '15 at 12:57
@MarvMills - my point was that although most PMs claim to be aware of it, they can't see past the cost part of the triangle. Now this isn't true across the board, but seen it too many times, especially when it's an internal project (i.e. the cost is coming out of a budget that someone x levels up has agreed, not someone authorising actual invoices for money).
– The Wandering Dev Manager
Nov 6 '15 at 13:00
 |Â
show 1 more comment
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
accepted
I believe this is a false dichotomy for the following reasons:
- The Project Manager should not try to enforce their opinions on software architecture, that is not their job. Their job is to manage the process of delivering a "product" against requirements. They do this by coordinating/utilising subject matter experts (e.g. Architects) within the project team to provide the necessary elements. If the PM holds (and attempts to implement) opinions on software architecture then the roles and responsibilities are blurred and it is that blurring that creates the problem. The roles and responsibilities of all project team members, including the PM, should be clearly defined in the Project Initiation Document and be unambiguously understood by all.
- Software Architecture will (presumably) assist in the design stages of a software project and therefore is responsible for producing elements of the deliverable. In that respect their outputs become part of the project deliverables and accordingly come under the supervision of the Project Manager. So for the purposes of the project they are part of the project team notionally managed by the project manager, but that does not mean the project manager can or should override them- that should not be the way project management works (see above)
So to summarise, in my opinion and in an ideal world, the architect "reports" to the PM (or more accurately contributes their expertise to the project the PM is managing), but the PM does not trump their input. I am sure there are many flavours of this arrangement in the real world, with all possible shades along the continuum, but the issue here is purely down to Roles and Responsibilities not being defined clearly and observed by all.
answered Nov 6 '15 at 12:00
Marv Mills
4,3831729
I like the answer but a PM can have an opinion about architecture but they should not dictate architecture. If a PM feels an architecture is putting a project at risk then it is fair to report that as a risk.
– paparazzo
Nov 6 '15 at 17:21
@Frisbee you are correct, of course, I got a bit carried away there. I will amend my answer accordingly
– Marv Mills
Nov 6 '15 at 18:14
suggest improvements |Â
up vote
5
down vote
accepted
I believe this is a false dichotomy for the following reasons:
- The Project Manager should not try to enforce their opinions on software architecture, that is not their job. Their job is to manage the process of delivering a "product" against requirements. They do this by coordinating/utilising subject matter experts (e.g. Architects) within the project team to provide the necessary elements. If the PM holds (and attempts to implement) opinions on software architecture then the roles and responsibilities are blurred and it is that blurring that creates the problem. The roles and responsibilities of all project team members, including the PM, should be clearly defined in the Project Initiation Document and be unambiguously understood by all.
- Software Architecture will (presumably) assist in the design stages of a software project and therefore is responsible for producing elements of the deliverable. In that respect their outputs become part of the project deliverables and accordingly come under the supervision of the Project Manager. So for the purposes of the project they are part of the project team notionally managed by the project manager, but that does not mean the project manager can or should override them- that should not be the way project management works (see above)
So to summarise, in my opinion and in an ideal world, the architect "reports" to the PM (or more accurately contributes their expertise to the project the PM is managing), but the PM does not trump their input. I am sure there are many flavours of this arrangement in the real world, with all possible shades along the continuum, but the issue here is purely down to Roles and Responsibilities not being defined clearly and observed by all.
answered Nov 6 '15 at 12:00
Marv Mills
4,3831729
I like the answer but a PM can have an opinion about architecture but they should not dictate architecture. If a PM feels an architecture is putting a project at risk then it is fair to report that as a risk.
– paparazzo
Nov 6 '15 at 17:21
@Frisbee you are correct, of course, I got a bit carried away there. I will amend my answer accordingly
– Marv Mills
Nov 6 '15 at 18:14
suggest improvements |Â
up vote
5
down vote
accepted
up vote
5
down vote
accepted
I believe this is a false dichotomy for the following reasons:
- The Project Manager should not try to enforce their opinions on software architecture, that is not their job. Their job is to manage the process of delivering a "product" against requirements. They do this by coordinating/utilising subject matter experts (e.g. Architects) within the project team to provide the necessary elements. If the PM holds (and attempts to implement) opinions on software architecture then the roles and responsibilities are blurred and it is that blurring that creates the problem. The roles and responsibilities of all project team members, including the PM, should be clearly defined in the Project Initiation Document and be unambiguously understood by all.
- Software Architecture will (presumably) assist in the design stages of a software project and therefore is responsible for producing elements of the deliverable. In that respect their outputs become part of the project deliverables and accordingly come under the supervision of the Project Manager. So for the purposes of the project they are part of the project team notionally managed by the project manager, but that does not mean the project manager can or should override them- that should not be the way project management works (see above)
So to summarise, in my opinion and in an ideal world, the architect "reports" to the PM (or more accurately contributes their expertise to the project the PM is managing), but the PM does not trump their input. I am sure there are many flavours of this arrangement in the real world, with all possible shades along the continuum, but the issue here is purely down to Roles and Responsibilities not being defined clearly and observed by all.
answered Nov 6 '15 at 12:00
Marv Mills
4,3831729
I believe this is a false dichotomy for the following reasons:
- The Project Manager should not try to enforce their opinions on software architecture, that is not their job. Their job is to manage the process of delivering a "product" against requirements. They do this by coordinating/utilising subject matter experts (e.g. Architects) within the project team to provide the necessary elements. If the PM holds (and attempts to implement) opinions on software architecture then the roles and responsibilities are blurred and it is that blurring that creates the problem. The roles and responsibilities of all project team members, including the PM, should be clearly defined in the Project Initiation Document and be unambiguously understood by all.
- Software Architecture will (presumably) assist in the design stages of a software project and therefore is responsible for producing elements of the deliverable. In that respect their outputs become part of the project deliverables and accordingly come under the supervision of the Project Manager. So for the purposes of the project they are part of the project team notionally managed by the project manager, but that does not mean the project manager can or should override them- that should not be the way project management works (see above)
So to summarise, in my opinion and in an ideal world, the architect "reports" to the PM (or more accurately contributes their expertise to the project the PM is managing), but the PM does not trump their input. I am sure there are many flavours of this arrangement in the real world, with all possible shades along the continuum, but the issue here is purely down to Roles and Responsibilities not being defined clearly and observed by all.
answered Nov 6 '15 at 12:00
Marv Mills
4,3831729
edited Nov 6 '15 at 18:15
answered Nov 6 '15 at 12:00
Marv Mills
4,3831729
answered Nov 6 '15 at 12:00
Marv Mills
4,3831729
answered Nov 6 '15 at 12:00
Marv Mills
4,3831729
4,3831729
I like the answer but a PM can have an opinion about architecture but they should not dictate architecture. If a PM feels an architecture is putting a project at risk then it is fair to report that as a risk.
– paparazzo
Nov 6 '15 at 17:21
@Frisbee you are correct, of course, I got a bit carried away there. I will amend my answer accordingly
– Marv Mills
Nov 6 '15 at 18:14
suggest improvements |Â
I like the answer but a PM can have an opinion about architecture but they should not dictate architecture. If a PM feels an architecture is putting a project at risk then it is fair to report that as a risk.
– paparazzo
Nov 6 '15 at 17:21
@Frisbee you are correct, of course, I got a bit carried away there. I will amend my answer accordingly
– Marv Mills
Nov 6 '15 at 18:14
I like the answer but a PM can have an opinion about architecture but they should not dictate architecture. If a PM feels an architecture is putting a project at risk then it is fair to report that as a risk.
– paparazzo
Nov 6 '15 at 17:21
I like the answer but a PM can have an opinion about architecture but they should not dictate architecture. If a PM feels an architecture is putting a project at risk then it is fair to report that as a risk.
– paparazzo
Nov 6 '15 at 17:21
@Frisbee you are correct, of course, I got a bit carried away there. I will amend my answer accordingly
– Marv Mills
Nov 6 '15 at 18:14
@Frisbee you are correct, of course, I got a bit carried away there. I will amend my answer accordingly
– Marv Mills
Nov 6 '15 at 18:14
suggest improvements |Â
up vote
2
down vote
While I agree with other answers on principle, I rarely experience such a pure and true form of Project Management discipline being practiced in the real corporate world.
It is important to look at where unspoken motivations exist to corrupt the intended motivations of the Project Manager. Yes on principle the Project Manager is responsible for delivering the project on budget and on time. It is important to remember that as the PM is the arbiter of Cost and Time, they are only representing 2 of the 3 core tenets of overall scope of work.
In most organizations, Project Managers are not inherently and naturally incentivized to give proper respect and attention to Quality, leading to the insatiably profound temptation for a PM on a struggling project to sacrifice Quality or influence development decisions to be made that favor Time and Cost at the expense of Quality.
This is the profound reason why Technical Architecture, operating at the high level design and focus on Quality Attributes, is so critically important that they not be bound by the reporting structure of the project in general. If the organization values the Technical Architect and Quality Attributes in software then they will not be held to project constraints and instead operate as a balance check against this. If you were to envision the role of a Technical Architect on an Agile organization they would be working closely with the Product Owner to define software needs and set expectations on high level design.
Would you also argue that the Project Manager should hold the Product Owner to task on defining software needs and scope? Of course not, that would be ridiculous.
The concept is the same. They exist as an important stakeholder in the project and not as a contributing member of the development team.
answered Nov 6 '15 at 17:46
maple_shaft
15.7k75296
suggest improvements |Â
up vote
2
down vote
While I agree with other answers on principle, I rarely experience such a pure and true form of Project Management discipline being practiced in the real corporate world.
It is important to look at where unspoken motivations exist to corrupt the intended motivations of the Project Manager. Yes on principle the Project Manager is responsible for delivering the project on budget and on time. It is important to remember that as the PM is the arbiter of Cost and Time, they are only representing 2 of the 3 core tenets of overall scope of work.
In most organizations, Project Managers are not inherently and naturally incentivized to give proper respect and attention to Quality, leading to the insatiably profound temptation for a PM on a struggling project to sacrifice Quality or influence development decisions to be made that favor Time and Cost at the expense of Quality.
This is the profound reason why Technical Architecture, operating at the high level design and focus on Quality Attributes, is so critically important that they not be bound by the reporting structure of the project in general. If the organization values the Technical Architect and Quality Attributes in software then they will not be held to project constraints and instead operate as a balance check against this. If you were to envision the role of a Technical Architect on an Agile organization they would be working closely with the Product Owner to define software needs and set expectations on high level design.
Would you also argue that the Project Manager should hold the Product Owner to task on defining software needs and scope? Of course not, that would be ridiculous.
The concept is the same. They exist as an important stakeholder in the project and not as a contributing member of the development team.
answered Nov 6 '15 at 17:46
maple_shaft
15.7k75296
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
While I agree with other answers on principle, I rarely experience such a pure and true form of Project Management discipline being practiced in the real corporate world.
It is important to look at where unspoken motivations exist to corrupt the intended motivations of the Project Manager. Yes on principle the Project Manager is responsible for delivering the project on budget and on time. It is important to remember that as the PM is the arbiter of Cost and Time, they are only representing 2 of the 3 core tenets of overall scope of work.
In most organizations, Project Managers are not inherently and naturally incentivized to give proper respect and attention to Quality, leading to the insatiably profound temptation for a PM on a struggling project to sacrifice Quality or influence development decisions to be made that favor Time and Cost at the expense of Quality.
This is the profound reason why Technical Architecture, operating at the high level design and focus on Quality Attributes, is so critically important that they not be bound by the reporting structure of the project in general. If the organization values the Technical Architect and Quality Attributes in software then they will not be held to project constraints and instead operate as a balance check against this. If you were to envision the role of a Technical Architect on an Agile organization they would be working closely with the Product Owner to define software needs and set expectations on high level design.
Would you also argue that the Project Manager should hold the Product Owner to task on defining software needs and scope? Of course not, that would be ridiculous.
The concept is the same. They exist as an important stakeholder in the project and not as a contributing member of the development team.
answered Nov 6 '15 at 17:46
maple_shaft
15.7k75296
While I agree with other answers on principle, I rarely experience such a pure and true form of Project Management discipline being practiced in the real corporate world.
It is important to look at where unspoken motivations exist to corrupt the intended motivations of the Project Manager. Yes on principle the Project Manager is responsible for delivering the project on budget and on time. It is important to remember that as the PM is the arbiter of Cost and Time, they are only representing 2 of the 3 core tenets of overall scope of work.
In most organizations, Project Managers are not inherently and naturally incentivized to give proper respect and attention to Quality, leading to the insatiably profound temptation for a PM on a struggling project to sacrifice Quality or influence development decisions to be made that favor Time and Cost at the expense of Quality.
This is the profound reason why Technical Architecture, operating at the high level design and focus on Quality Attributes, is so critically important that they not be bound by the reporting structure of the project in general. If the organization values the Technical Architect and Quality Attributes in software then they will not be held to project constraints and instead operate as a balance check against this. If you were to envision the role of a Technical Architect on an Agile organization they would be working closely with the Product Owner to define software needs and set expectations on high level design.
Would you also argue that the Project Manager should hold the Product Owner to task on defining software needs and scope? Of course not, that would be ridiculous.
The concept is the same. They exist as an important stakeholder in the project and not as a contributing member of the development team.
answered Nov 6 '15 at 17:46
maple_shaft
15.7k75296
answered Nov 6 '15 at 17:46
maple_shaft
15.7k75296
answered Nov 6 '15 at 17:46
maple_shaft
15.7k75296
answered Nov 6 '15 at 17:46
maple_shaft
15.7k75296
15.7k75296
suggest improvements |Â
suggest improvements |Â
up vote
1
down vote
The Architect should report to the person responsible for managing the development team, typically this would be a development manager, but in smaller shops it could be a general IT manager. The PM should report to the business manager, however often times the PM is assigned to the IT department in which case the PM should report to the person responsible for the IT Business, which in smaller shops could be the same person that manages development.
Those roles are for day to day general management responsibilities(Attendance, performance reviews, work assignments). For project responsibilities the Architect is going to have to report progress, problems, and planning to the PM. If the design proposed does not meet business needs for some reason, like it will take to long to implement, it is the PM's call. Generally if the architect, and the PM cannot find an acceptable solution it would escalate to the higher management levels to make final decisions.
Many times these decisions will mean varying from best practices, or standards that have been put in place to meet business demands. It is the job of the architect to then figure out how to meet the new requirements outside of the practices, and make a plan for how to correct these problems once the time crunch is over. Do not keep fighting a battle that is already lost unless some new serious concern takes place.
tl;dr; It is the job of the architect to attempt to provide the project manager with the design they request inside of the parameters they request.
answered Nov 6 '15 at 16:09
IDrinkandIKnowThings
43.8k1397187
This term Architect is used so loosely in the industry that it is clear everybody will have a different answer because everybody has a different experience with what an Architect should be. My answer takes more of an SEI view of the role of software architecture. In my opinion, what you are calling the architect here sounds more like a Project Technical Lead which I think is an important distinction. There is some overlap though.
– maple_shaft
Nov 6 '15 at 17:49
@maple_shaft - Not really an architect is usually involved in the early design development effort. An architect usually takes his hands off when its time to do the heavy lifting of doing actual work, that's when the (good) tech lead digs in and works the hardest. But I agree everyone has a different opinion on what an architect should do. Devs think they should do more work, pms think they should get their nose out of their project... etc.
– IDrinkandIKnowThings
Nov 6 '15 at 19:53
suggest improvements |Â
up vote
1
down vote
The Architect should report to the person responsible for managing the development team, typically this would be a development manager, but in smaller shops it could be a general IT manager. The PM should report to the business manager, however often times the PM is assigned to the IT department in which case the PM should report to the person responsible for the IT Business, which in smaller shops could be the same person that manages development.
Those roles are for day to day general management responsibilities(Attendance, performance reviews, work assignments). For project responsibilities the Architect is going to have to report progress, problems, and planning to the PM. If the design proposed does not meet business needs for some reason, like it will take to long to implement, it is the PM's call. Generally if the architect, and the PM cannot find an acceptable solution it would escalate to the higher management levels to make final decisions.
Many times these decisions will mean varying from best practices, or standards that have been put in place to meet business demands. It is the job of the architect to then figure out how to meet the new requirements outside of the practices, and make a plan for how to correct these problems once the time crunch is over. Do not keep fighting a battle that is already lost unless some new serious concern takes place.
tl;dr; It is the job of the architect to attempt to provide the project manager with the design they request inside of the parameters they request.
answered Nov 6 '15 at 16:09
IDrinkandIKnowThings
43.8k1397187
This term Architect is used so loosely in the industry that it is clear everybody will have a different answer because everybody has a different experience with what an Architect should be. My answer takes more of an SEI view of the role of software architecture. In my opinion, what you are calling the architect here sounds more like a Project Technical Lead which I think is an important distinction. There is some overlap though.
– maple_shaft
Nov 6 '15 at 17:49
@maple_shaft - Not really an architect is usually involved in the early design development effort. An architect usually takes his hands off when its time to do the heavy lifting of doing actual work, that's when the (good) tech lead digs in and works the hardest. But I agree everyone has a different opinion on what an architect should do. Devs think they should do more work, pms think they should get their nose out of their project... etc.
– IDrinkandIKnowThings
Nov 6 '15 at 19:53
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
The Architect should report to the person responsible for managing the development team, typically this would be a development manager, but in smaller shops it could be a general IT manager. The PM should report to the business manager, however often times the PM is assigned to the IT department in which case the PM should report to the person responsible for the IT Business, which in smaller shops could be the same person that manages development.
Those roles are for day to day general management responsibilities(Attendance, performance reviews, work assignments). For project responsibilities the Architect is going to have to report progress, problems, and planning to the PM. If the design proposed does not meet business needs for some reason, like it will take to long to implement, it is the PM's call. Generally if the architect, and the PM cannot find an acceptable solution it would escalate to the higher management levels to make final decisions.
Many times these decisions will mean varying from best practices, or standards that have been put in place to meet business demands. It is the job of the architect to then figure out how to meet the new requirements outside of the practices, and make a plan for how to correct these problems once the time crunch is over. Do not keep fighting a battle that is already lost unless some new serious concern takes place.
tl;dr; It is the job of the architect to attempt to provide the project manager with the design they request inside of the parameters they request.
answered Nov 6 '15 at 16:09
IDrinkandIKnowThings
43.8k1397187
The Architect should report to the person responsible for managing the development team, typically this would be a development manager, but in smaller shops it could be a general IT manager. The PM should report to the business manager, however often times the PM is assigned to the IT department in which case the PM should report to the person responsible for the IT Business, which in smaller shops could be the same person that manages development.
Those roles are for day to day general management responsibilities(Attendance, performance reviews, work assignments). For project responsibilities the Architect is going to have to report progress, problems, and planning to the PM. If the design proposed does not meet business needs for some reason, like it will take to long to implement, it is the PM's call. Generally if the architect, and the PM cannot find an acceptable solution it would escalate to the higher management levels to make final decisions.
Many times these decisions will mean varying from best practices, or standards that have been put in place to meet business demands. It is the job of the architect to then figure out how to meet the new requirements outside of the practices, and make a plan for how to correct these problems once the time crunch is over. Do not keep fighting a battle that is already lost unless some new serious concern takes place.
tl;dr; It is the job of the architect to attempt to provide the project manager with the design they request inside of the parameters they request.
answered Nov 6 '15 at 16:09
IDrinkandIKnowThings
43.8k1397187
answered Nov 6 '15 at 16:09
IDrinkandIKnowThings
43.8k1397187
answered Nov 6 '15 at 16:09
IDrinkandIKnowThings
43.8k1397187
answered Nov 6 '15 at 16:09
IDrinkandIKnowThings
43.8k1397187
43.8k1397187
This term Architect is used so loosely in the industry that it is clear everybody will have a different answer because everybody has a different experience with what an Architect should be. My answer takes more of an SEI view of the role of software architecture. In my opinion, what you are calling the architect here sounds more like a Project Technical Lead which I think is an important distinction. There is some overlap though.
– maple_shaft
Nov 6 '15 at 17:49
@maple_shaft - Not really an architect is usually involved in the early design development effort. An architect usually takes his hands off when its time to do the heavy lifting of doing actual work, that's when the (good) tech lead digs in and works the hardest. But I agree everyone has a different opinion on what an architect should do. Devs think they should do more work, pms think they should get their nose out of their project... etc.
– IDrinkandIKnowThings
Nov 6 '15 at 19:53
suggest improvements |Â
This term Architect is used so loosely in the industry that it is clear everybody will have a different answer because everybody has a different experience with what an Architect should be. My answer takes more of an SEI view of the role of software architecture. In my opinion, what you are calling the architect here sounds more like a Project Technical Lead which I think is an important distinction. There is some overlap though.
– maple_shaft
Nov 6 '15 at 17:49
@maple_shaft - Not really an architect is usually involved in the early design development effort. An architect usually takes his hands off when its time to do the heavy lifting of doing actual work, that's when the (good) tech lead digs in and works the hardest. But I agree everyone has a different opinion on what an architect should do. Devs think they should do more work, pms think they should get their nose out of their project... etc.
– IDrinkandIKnowThings
Nov 6 '15 at 19:53
This term Architect is used so loosely in the industry that it is clear everybody will have a different answer because everybody has a different experience with what an Architect should be. My answer takes more of an SEI view of the role of software architecture. In my opinion, what you are calling the architect here sounds more like a Project Technical Lead which I think is an important distinction. There is some overlap though.
– maple_shaft
Nov 6 '15 at 17:49
This term Architect is used so loosely in the industry that it is clear everybody will have a different answer because everybody has a different experience with what an Architect should be. My answer takes more of an SEI view of the role of software architecture. In my opinion, what you are calling the architect here sounds more like a Project Technical Lead which I think is an important distinction. There is some overlap though.
– maple_shaft
Nov 6 '15 at 17:49
@maple_shaft - Not really an architect is usually involved in the early design development effort. An architect usually takes his hands off when its time to do the heavy lifting of doing actual work, that's when the (good) tech lead digs in and works the hardest. But I agree everyone has a different opinion on what an architect should do. Devs think they should do more work, pms think they should get their nose out of their project... etc.
– IDrinkandIKnowThings
Nov 6 '15 at 19:53
@maple_shaft - Not really an architect is usually involved in the early design development effort. An architect usually takes his hands off when its time to do the heavy lifting of doing actual work, that's when the (good) tech lead digs in and works the hardest. But I agree everyone has a different opinion on what an architect should do. Devs think they should do more work, pms think they should get their nose out of their project... etc.
– IDrinkandIKnowThings
Nov 6 '15 at 19:53
suggest improvements |Â
up vote
-2
down vote
Assuming you mean reports in the meaning of "works for" (obviously an architect should report progress to a PM if relevant), the simple answer is this:
No delivery team members should be managed by a PM, there is a conflict of interest
The PM's job is to make sure the project is delivered on time and for minimum cost. The delivery team (especially architects as in the example) have a responsibility to deliver a fit-for-purpose design and implementation, and this could well not fit within the PM's plan, and a project requires compromises on both sides to deliver.
Giving one side ultimate authority will create an unassailable situation (been there), where the project is badly compromised to meet time and/or budget. Alternately with PM in tow to architecture you end up with a Duke-Nuke'em Forever situation where nothing ships as it needs to be refined/refactored.
You need technical delivery and project management on opposing sides to challenge each other, by this way a good project lies (although it may not feel like it at the time).
answered Nov 6 '15 at 12:12
The Wandering Dev Manager
29.8k956107
One little pedantic point, I don't see it as the PM's responsibility to deliver the project to "minimum cost". The PM's responsibility is to deliver the project to the agreed cost as driven by the requirements and defined in the project mandate (whatever form that takes). Plus of course there is the third point on the triangle; "quality", i.e. it has to meet requirements. However I am sure I am preaching to the choir on all this :)
– Marv Mills
Nov 6 '15 at 12:30
Well in 20+ years of software projects, agreed cost=happy path cost= minimum cost. And despite what PMs say the third point on the triangle is just out of vision due to the big honking cost one filling their vision. My point is though that you need this conflict, it is a healthy debate on project delivery, and the failures are ones where one side is stronger and tilts the project their way.
– The Wandering Dev Manager
Nov 6 '15 at 12:52
Only 20? N00b then ;) I certainly agree with the "conflict" as a good thing as described here, no argument from me- you need both sides pulling to produce the "right" outcome. But I don't really understand your point about quality being "just out of vision". Anyway, as this isn't a discussion site I guess we'll leave it there.
– Marv Mills
Nov 6 '15 at 12:56
I'm sure all have been on projects where cost prioritisation has built a unmaintainable failure. I've also been on the other side. Once spent 18 months with a public sector team, technical but no PM. Kept fitting in what the customer wanted (medical), plus work on code. In version 10 when I arrived, and had never gone live in production, only invited beta (4 years of a team of 8). It never went live, was eventually scrapped when another part of the system was refactored and the need for it went away.
– The Wandering Dev Manager
Nov 6 '15 at 12:57
@MarvMills - my point was that although most PMs claim to be aware of it, they can't see past the cost part of the triangle. Now this isn't true across the board, but seen it too many times, especially when it's an internal project (i.e. the cost is coming out of a budget that someone x levels up has agreed, not someone authorising actual invoices for money).
– The Wandering Dev Manager
Nov 6 '15 at 13:00
 |Â
show 1 more comment
up vote
-2
down vote
Assuming you mean reports in the meaning of "works for" (obviously an architect should report progress to a PM if relevant), the simple answer is this:
No delivery team members should be managed by a PM, there is a conflict of interest
The PM's job is to make sure the project is delivered on time and for minimum cost. The delivery team (especially architects as in the example) have a responsibility to deliver a fit-for-purpose design and implementation, and this could well not fit within the PM's plan, and a project requires compromises on both sides to deliver.
Giving one side ultimate authority will create an unassailable situation (been there), where the project is badly compromised to meet time and/or budget. Alternately with PM in tow to architecture you end up with a Duke-Nuke'em Forever situation where nothing ships as it needs to be refined/refactored.
You need technical delivery and project management on opposing sides to challenge each other, by this way a good project lies (although it may not feel like it at the time).
answered Nov 6 '15 at 12:12
The Wandering Dev Manager
29.8k956107
One little pedantic point, I don't see it as the PM's responsibility to deliver the project to "minimum cost". The PM's responsibility is to deliver the project to the agreed cost as driven by the requirements and defined in the project mandate (whatever form that takes). Plus of course there is the third point on the triangle; "quality", i.e. it has to meet requirements. However I am sure I am preaching to the choir on all this :)
– Marv Mills
Nov 6 '15 at 12:30
Well in 20+ years of software projects, agreed cost=happy path cost= minimum cost. And despite what PMs say the third point on the triangle is just out of vision due to the big honking cost one filling their vision. My point is though that you need this conflict, it is a healthy debate on project delivery, and the failures are ones where one side is stronger and tilts the project their way.
– The Wandering Dev Manager
Nov 6 '15 at 12:52
Only 20? N00b then ;) I certainly agree with the "conflict" as a good thing as described here, no argument from me- you need both sides pulling to produce the "right" outcome. But I don't really understand your point about quality being "just out of vision". Anyway, as this isn't a discussion site I guess we'll leave it there.
– Marv Mills
Nov 6 '15 at 12:56
I'm sure all have been on projects where cost prioritisation has built a unmaintainable failure. I've also been on the other side. Once spent 18 months with a public sector team, technical but no PM. Kept fitting in what the customer wanted (medical), plus work on code. In version 10 when I arrived, and had never gone live in production, only invited beta (4 years of a team of 8). It never went live, was eventually scrapped when another part of the system was refactored and the need for it went away.
– The Wandering Dev Manager
Nov 6 '15 at 12:57
@MarvMills - my point was that although most PMs claim to be aware of it, they can't see past the cost part of the triangle. Now this isn't true across the board, but seen it too many times, especially when it's an internal project (i.e. the cost is coming out of a budget that someone x levels up has agreed, not someone authorising actual invoices for money).
– The Wandering Dev Manager
Nov 6 '15 at 13:00
 |Â
show 1 more comment
up vote
-2
down vote
up vote
-2
down vote
Assuming you mean reports in the meaning of "works for" (obviously an architect should report progress to a PM if relevant), the simple answer is this:
No delivery team members should be managed by a PM, there is a conflict of interest
The PM's job is to make sure the project is delivered on time and for minimum cost. The delivery team (especially architects as in the example) have a responsibility to deliver a fit-for-purpose design and implementation, and this could well not fit within the PM's plan, and a project requires compromises on both sides to deliver.
Giving one side ultimate authority will create an unassailable situation (been there), where the project is badly compromised to meet time and/or budget. Alternately with PM in tow to architecture you end up with a Duke-Nuke'em Forever situation where nothing ships as it needs to be refined/refactored.
You need technical delivery and project management on opposing sides to challenge each other, by this way a good project lies (although it may not feel like it at the time).
answered Nov 6 '15 at 12:12
The Wandering Dev Manager
29.8k956107
Assuming you mean reports in the meaning of "works for" (obviously an architect should report progress to a PM if relevant), the simple answer is this:
No delivery team members should be managed by a PM, there is a conflict of interest
The PM's job is to make sure the project is delivered on time and for minimum cost. The delivery team (especially architects as in the example) have a responsibility to deliver a fit-for-purpose design and implementation, and this could well not fit within the PM's plan, and a project requires compromises on both sides to deliver.
Giving one side ultimate authority will create an unassailable situation (been there), where the project is badly compromised to meet time and/or budget. Alternately with PM in tow to architecture you end up with a Duke-Nuke'em Forever situation where nothing ships as it needs to be refined/refactored.
You need technical delivery and project management on opposing sides to challenge each other, by this way a good project lies (although it may not feel like it at the time).
answered Nov 6 '15 at 12:12
The Wandering Dev Manager
29.8k956107
answered Nov 6 '15 at 12:12
The Wandering Dev Manager
29.8k956107
answered Nov 6 '15 at 12:12
The Wandering Dev Manager
29.8k956107
answered Nov 6 '15 at 12:12
The Wandering Dev Manager
29.8k956107
29.8k956107
One little pedantic point, I don't see it as the PM's responsibility to deliver the project to "minimum cost". The PM's responsibility is to deliver the project to the agreed cost as driven by the requirements and defined in the project mandate (whatever form that takes). Plus of course there is the third point on the triangle; "quality", i.e. it has to meet requirements. However I am sure I am preaching to the choir on all this :)
– Marv Mills
Nov 6 '15 at 12:30
Well in 20+ years of software projects, agreed cost=happy path cost= minimum cost. And despite what PMs say the third point on the triangle is just out of vision due to the big honking cost one filling their vision. My point is though that you need this conflict, it is a healthy debate on project delivery, and the failures are ones where one side is stronger and tilts the project their way.
– The Wandering Dev Manager
Nov 6 '15 at 12:52
Only 20? N00b then ;) I certainly agree with the "conflict" as a good thing as described here, no argument from me- you need both sides pulling to produce the "right" outcome. But I don't really understand your point about quality being "just out of vision". Anyway, as this isn't a discussion site I guess we'll leave it there.
– Marv Mills
Nov 6 '15 at 12:56
I'm sure all have been on projects where cost prioritisation has built a unmaintainable failure. I've also been on the other side. Once spent 18 months with a public sector team, technical but no PM. Kept fitting in what the customer wanted (medical), plus work on code. In version 10 when I arrived, and had never gone live in production, only invited beta (4 years of a team of 8). It never went live, was eventually scrapped when another part of the system was refactored and the need for it went away.
– The Wandering Dev Manager
Nov 6 '15 at 12:57
@MarvMills - my point was that although most PMs claim to be aware of it, they can't see past the cost part of the triangle. Now this isn't true across the board, but seen it too many times, especially when it's an internal project (i.e. the cost is coming out of a budget that someone x levels up has agreed, not someone authorising actual invoices for money).
– The Wandering Dev Manager
Nov 6 '15 at 13:00
 |Â
show 1 more comment
One little pedantic point, I don't see it as the PM's responsibility to deliver the project to "minimum cost". The PM's responsibility is to deliver the project to the agreed cost as driven by the requirements and defined in the project mandate (whatever form that takes). Plus of course there is the third point on the triangle; "quality", i.e. it has to meet requirements. However I am sure I am preaching to the choir on all this :)
– Marv Mills
Nov 6 '15 at 12:30
Well in 20+ years of software projects, agreed cost=happy path cost= minimum cost. And despite what PMs say the third point on the triangle is just out of vision due to the big honking cost one filling their vision. My point is though that you need this conflict, it is a healthy debate on project delivery, and the failures are ones where one side is stronger and tilts the project their way.
– The Wandering Dev Manager
Nov 6 '15 at 12:52
Only 20? N00b then ;) I certainly agree with the "conflict" as a good thing as described here, no argument from me- you need both sides pulling to produce the "right" outcome. But I don't really understand your point about quality being "just out of vision". Anyway, as this isn't a discussion site I guess we'll leave it there.
– Marv Mills
Nov 6 '15 at 12:56
I'm sure all have been on projects where cost prioritisation has built a unmaintainable failure. I've also been on the other side. Once spent 18 months with a public sector team, technical but no PM. Kept fitting in what the customer wanted (medical), plus work on code. In version 10 when I arrived, and had never gone live in production, only invited beta (4 years of a team of 8). It never went live, was eventually scrapped when another part of the system was refactored and the need for it went away.
– The Wandering Dev Manager
Nov 6 '15 at 12:57
@MarvMills - my point was that although most PMs claim to be aware of it, they can't see past the cost part of the triangle. Now this isn't true across the board, but seen it too many times, especially when it's an internal project (i.e. the cost is coming out of a budget that someone x levels up has agreed, not someone authorising actual invoices for money).
– The Wandering Dev Manager
Nov 6 '15 at 13:00
One little pedantic point, I don't see it as the PM's responsibility to deliver the project to "minimum cost". The PM's responsibility is to deliver the project to the agreed cost as driven by the requirements and defined in the project mandate (whatever form that takes). Plus of course there is the third point on the triangle; "quality", i.e. it has to meet requirements. However I am sure I am preaching to the choir on all this :)
– Marv Mills
Nov 6 '15 at 12:30
One little pedantic point, I don't see it as the PM's responsibility to deliver the project to "minimum cost". The PM's responsibility is to deliver the project to the agreed cost as driven by the requirements and defined in the project mandate (whatever form that takes). Plus of course there is the third point on the triangle; "quality", i.e. it has to meet requirements. However I am sure I am preaching to the choir on all this :)
– Marv Mills
Nov 6 '15 at 12:30
Well in 20+ years of software projects, agreed cost=happy path cost= minimum cost. And despite what PMs say the third point on the triangle is just out of vision due to the big honking cost one filling their vision. My point is though that you need this conflict, it is a healthy debate on project delivery, and the failures are ones where one side is stronger and tilts the project their way.
– The Wandering Dev Manager
Nov 6 '15 at 12:52
Well in 20+ years of software projects, agreed cost=happy path cost= minimum cost. And despite what PMs say the third point on the triangle is just out of vision due to the big honking cost one filling their vision. My point is though that you need this conflict, it is a healthy debate on project delivery, and the failures are ones where one side is stronger and tilts the project their way.
– The Wandering Dev Manager
Nov 6 '15 at 12:52
Only 20? N00b then ;) I certainly agree with the "conflict" as a good thing as described here, no argument from me- you need both sides pulling to produce the "right" outcome. But I don't really understand your point about quality being "just out of vision". Anyway, as this isn't a discussion site I guess we'll leave it there.
– Marv Mills
Nov 6 '15 at 12:56
Only 20? N00b then ;) I certainly agree with the "conflict" as a good thing as described here, no argument from me- you need both sides pulling to produce the "right" outcome. But I don't really understand your point about quality being "just out of vision". Anyway, as this isn't a discussion site I guess we'll leave it there.
– Marv Mills
Nov 6 '15 at 12:56
I'm sure all have been on projects where cost prioritisation has built a unmaintainable failure. I've also been on the other side. Once spent 18 months with a public sector team, technical but no PM. Kept fitting in what the customer wanted (medical), plus work on code. In version 10 when I arrived, and had never gone live in production, only invited beta (4 years of a team of 8). It never went live, was eventually scrapped when another part of the system was refactored and the need for it went away.
– The Wandering Dev Manager
Nov 6 '15 at 12:57
I'm sure all have been on projects where cost prioritisation has built a unmaintainable failure. I've also been on the other side. Once spent 18 months with a public sector team, technical but no PM. Kept fitting in what the customer wanted (medical), plus work on code. In version 10 when I arrived, and had never gone live in production, only invited beta (4 years of a team of 8). It never went live, was eventually scrapped when another part of the system was refactored and the need for it went away.
– The Wandering Dev Manager
Nov 6 '15 at 12:57
@MarvMills - my point was that although most PMs claim to be aware of it, they can't see past the cost part of the triangle. Now this isn't true across the board, but seen it too many times, especially when it's an internal project (i.e. the cost is coming out of a budget that someone x levels up has agreed, not someone authorising actual invoices for money).
– The Wandering Dev Manager
Nov 6 '15 at 13:00
@MarvMills - my point was that although most PMs claim to be aware of it, they can't see past the cost part of the triangle. Now this isn't true across the board, but seen it too many times, especially when it's an internal project (i.e. the cost is coming out of a budget that someone x levels up has agreed, not someone authorising actual invoices for money).
– The Wandering Dev Manager
Nov 6 '15 at 13:00
 |Â
show 1 more comment
3
In my company they are of equal rank and both report upwards. I don't know if this is standard practice or even best practice. In fact my observation is that it seems to breed conflict.
– Dustybin80
Nov 6 '15 at 11:33
1
This seems so dependent on the situation and your definition of the titles involved that I'm not sure there's a useful answer or universal best practice.
– Lilienthal♦
Nov 6 '15 at 12:15
I don't agree a PM does not guard quality.
– paparazzo
Nov 6 '15 at 17:14
1
I think it is completely incorrect that this has been closed as company-specific. There is nothing in the question that is company specific. The roles in question are generic and widespread roles and the hierarchy of roles is both fairly standard and debatable. I propose the OP posts this question on the Project Management SE here (pm.stackexchange.com/questions) where it may be better understood
– Marv Mills
Nov 6 '15 at 18:18