Mixing
![Is it appropriate to make suggestions for future projects? [closed]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjbpfN9tAutmK93bJRC3ZoROZzi2TJDms5n8_qJuhgE0a9b52OOHayv3NGT8igAdFL7byXNst-_1DZK5SjrIJ28_6RQPUpBROqMs5s6jo-ZsjX8kjDwfxJufIitH3TaQRXWaGSQKRQib-f/s72-c/1.jpg)
How to deal with too many requirement changes which are not documented at one place [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
0
down vote
favorite
I am a lead developer working for the IT department of an organization. Recently I have been assigned a new project. Initially, the business analyst responsible for the project sent me developer requirements. After I reviewed those documents, I noticed that there were lot of gaps and that clarity was missing, which I brought back to the business analyst. Similarly, other team members also come up with clarification questions related their part of development work. It took a month and a half to clear up this confusion on the requirements. However the problem isn't all these requirement clarifications, but instead it's in the fact that not all of these changes are documented in any central location and aren't updated in the original project specializations. As a result, the gap between the initially specified requirements in the requirement document and the finalized requirements is so high.
Thus, not everyone involved in the project is on the same page, and every time I need to explain the history of how the initial requirements changed to current one. I feel it is not productive and is tedious.
Here My primary problem is all the latest changes are not updated in requirement docs. Due to this I am facing issues like other colleagues asking too many questions about requirements. Hence the root cause is not updating all the updates about requirements in the original document, I am asking question about that only. Hence my question would become
How to deal with too many requirement changes and not updated/documented in single place?
software-industry
asked Apr 10 '14 at 2:18
vehitha
4602512
closed as unclear what you're asking by IDrinkandIKnowThings, jmac Apr 10 '14 at 7:11
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
 |Â
show 2 more comments
up vote
0
down vote
favorite
I am a lead developer working for the IT department of an organization. Recently I have been assigned a new project. Initially, the business analyst responsible for the project sent me developer requirements. After I reviewed those documents, I noticed that there were lot of gaps and that clarity was missing, which I brought back to the business analyst. Similarly, other team members also come up with clarification questions related their part of development work. It took a month and a half to clear up this confusion on the requirements. However the problem isn't all these requirement clarifications, but instead it's in the fact that not all of these changes are documented in any central location and aren't updated in the original project specializations. As a result, the gap between the initially specified requirements in the requirement document and the finalized requirements is so high.
Thus, not everyone involved in the project is on the same page, and every time I need to explain the history of how the initial requirements changed to current one. I feel it is not productive and is tedious.
Here My primary problem is all the latest changes are not updated in requirement docs. Due to this I am facing issues like other colleagues asking too many questions about requirements. Hence the root cause is not updating all the updates about requirements in the original document, I am asking question about that only. Hence my question would become
How to deal with too many requirement changes and not updated/documented in single place?
software-industry
asked Apr 10 '14 at 2:18
vehitha
4602512
closed as unclear what you're asking by IDrinkandIKnowThings, jmac Apr 10 '14 at 7:11
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
This question appears to be off-topic because it is a question about programming not navigating the workplace.
– IDrinkandIKnowThings
Apr 10 '14 at 4:08
@Chad - I disagree, it's a question on project management, not programming. It just happens to involve a programming project.
– panoptical
Apr 10 '14 at 4:10
OK then it belongs on PM.SE It is not about navigating the workplace
– IDrinkandIKnowThings
Apr 10 '14 at 4:10
That I do agree with (didn't know there was a Project Management SE).
– panoptical
Apr 10 '14 at 4:21
Mmm...fragmentation.
– aroth
Apr 10 '14 at 5:06
 |Â
show 2 more comments
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am a lead developer working for the IT department of an organization. Recently I have been assigned a new project. Initially, the business analyst responsible for the project sent me developer requirements. After I reviewed those documents, I noticed that there were lot of gaps and that clarity was missing, which I brought back to the business analyst. Similarly, other team members also come up with clarification questions related their part of development work. It took a month and a half to clear up this confusion on the requirements. However the problem isn't all these requirement clarifications, but instead it's in the fact that not all of these changes are documented in any central location and aren't updated in the original project specializations. As a result, the gap between the initially specified requirements in the requirement document and the finalized requirements is so high.
Thus, not everyone involved in the project is on the same page, and every time I need to explain the history of how the initial requirements changed to current one. I feel it is not productive and is tedious.
Here My primary problem is all the latest changes are not updated in requirement docs. Due to this I am facing issues like other colleagues asking too many questions about requirements. Hence the root cause is not updating all the updates about requirements in the original document, I am asking question about that only. Hence my question would become
How to deal with too many requirement changes and not updated/documented in single place?
software-industry
asked Apr 10 '14 at 2:18
vehitha
4602512
I am a lead developer working for the IT department of an organization. Recently I have been assigned a new project. Initially, the business analyst responsible for the project sent me developer requirements. After I reviewed those documents, I noticed that there were lot of gaps and that clarity was missing, which I brought back to the business analyst. Similarly, other team members also come up with clarification questions related their part of development work. It took a month and a half to clear up this confusion on the requirements. However the problem isn't all these requirement clarifications, but instead it's in the fact that not all of these changes are documented in any central location and aren't updated in the original project specializations. As a result, the gap between the initially specified requirements in the requirement document and the finalized requirements is so high.
Thus, not everyone involved in the project is on the same page, and every time I need to explain the history of how the initial requirements changed to current one. I feel it is not productive and is tedious.
Here My primary problem is all the latest changes are not updated in requirement docs. Due to this I am facing issues like other colleagues asking too many questions about requirements. Hence the root cause is not updating all the updates about requirements in the original document, I am asking question about that only. Hence my question would become
How to deal with too many requirement changes and not updated/documented in single place?
software-industry
asked Apr 10 '14 at 2:18
vehitha
4602512
edited Apr 11 '14 at 0:17
asked Apr 10 '14 at 2:18
vehitha
4602512
asked Apr 10 '14 at 2:18
vehitha
4602512
asked Apr 10 '14 at 2:18
vehitha
4602512
4602512
closed as unclear what you're asking by IDrinkandIKnowThings, jmac Apr 10 '14 at 7:11
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as unclear what you're asking by IDrinkandIKnowThings, jmac Apr 10 '14 at 7:11
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
This question appears to be off-topic because it is a question about programming not navigating the workplace.
– IDrinkandIKnowThings
Apr 10 '14 at 4:08
@Chad - I disagree, it's a question on project management, not programming. It just happens to involve a programming project.
– panoptical
Apr 10 '14 at 4:10
OK then it belongs on PM.SE It is not about navigating the workplace
– IDrinkandIKnowThings
Apr 10 '14 at 4:10
That I do agree with (didn't know there was a Project Management SE).
– panoptical
Apr 10 '14 at 4:21
Mmm...fragmentation.
– aroth
Apr 10 '14 at 5:06
 |Â
show 2 more comments
This question appears to be off-topic because it is a question about programming not navigating the workplace.
– IDrinkandIKnowThings
Apr 10 '14 at 4:08
@Chad - I disagree, it's a question on project management, not programming. It just happens to involve a programming project.
– panoptical
Apr 10 '14 at 4:10
OK then it belongs on PM.SE It is not about navigating the workplace
– IDrinkandIKnowThings
Apr 10 '14 at 4:10
That I do agree with (didn't know there was a Project Management SE).
– panoptical
Apr 10 '14 at 4:21
Mmm...fragmentation.
– aroth
Apr 10 '14 at 5:06
This question appears to be off-topic because it is a question about programming not navigating the workplace.
– IDrinkandIKnowThings
Apr 10 '14 at 4:08
This question appears to be off-topic because it is a question about programming not navigating the workplace.
– IDrinkandIKnowThings
Apr 10 '14 at 4:08
@Chad - I disagree, it's a question on project management, not programming. It just happens to involve a programming project.
– panoptical
Apr 10 '14 at 4:10
@Chad - I disagree, it's a question on project management, not programming. It just happens to involve a programming project.
– panoptical
Apr 10 '14 at 4:10
OK then it belongs on PM.SE It is not about navigating the workplace
– IDrinkandIKnowThings
Apr 10 '14 at 4:10
OK then it belongs on PM.SE It is not about navigating the workplace
– IDrinkandIKnowThings
Apr 10 '14 at 4:10
That I do agree with (didn't know there was a Project Management SE).
– panoptical
Apr 10 '14 at 4:21
That I do agree with (didn't know there was a Project Management SE).
– panoptical
Apr 10 '14 at 4:21
Mmm...fragmentation.
– aroth
Apr 10 '14 at 5:06
Mmm...fragmentation.
– aroth
Apr 10 '14 at 5:06
 |Â
show 2 more comments
2 Answers
2
active
oldest
votes
up vote
2
down vote
It's really not terribly complicated. You, or your boss, or someone on up the chain needs to assign a project manager to the project. That manager would be responsible for organizing all the requirements, constructing a timeline (and making sure each team is sticking to that timeline), and managing the budget for the project. This manager would be the point man (or woman) for the entire project, and would allow for a central point of organization for the requirements.
In larger firms, project managers are actually job titles, and those people are usually dedicated to doing the above for 1 or a handful of projects. In smaller firms, it may be one person wearing multiple hats as part of the project, one of which reads project manager.
answered Apr 10 '14 at 2:42
panoptical
3,5761538
add a comment |Â
up vote
2
down vote
However the problem is all these requirement clarifications,
discussions summary is in Emails not documented single place and not
updated in original requirement documents.
That is a problem. So why not document the changes somewhere centralized and easily accessible? Does your company run a wiki (or if not, then why not?)?
That's where your requirements documentation should live, and any discussions that happen in relation to the requirements should be attached there. The requirements themselves should be updated in the main document as changes are agreed upon, and each change should be scoped as it is applied to the main requirements document. Your wiki will maintain a log of all changes as they are made, making it easy to view how the requirements have evolved over time. And it can also be configured to notify all members of the development team whenever a change is made, ensuring that everyone is kept informed of changes as they are made.
If your company is not running a wiki, then your immediate task is: Convince your manager(s) that they really, really need to be running a wiki or some comparable solution.
And also due to many changes in the requirements the gap between
initially specified requirements in the requirement document and the
finalized requirements is so high.
Software requirements are never finalized. If the requirements have changed then you really need to update your "finalized" requirements document to reflect the changes. Otherwise you run into exactly the issues you are describing.
If you find it too disruptive to work off of a "living" requirements document (which it certainly can be), you can take a snapshot of the requirements (or some subset of requirements) and call that your Minimum Viable Product. Then your MVP requirements can stay fixed, and that's what you build your initial release towards. Any changes to the requirements are recorded against the main document (or within the product backlog, if you are using agile/Scrum), and you deal with them after completing your MVP implementation.
The problem is not every one who are working for the project on the
same page. And every time I need explain the history how initial
requirements changed to current one. I feel it is not productive and
tedious.
How can I deal with it?
You should:
- Establish a canonical "source of truth" that everyone can use to see the current requirements. A wiki works wonders for this.
- Ensure that information related to the how and why of your changing requirements is documented and accessible from your "source of truth". If a requirement changes because of an e-mail exchange, attach the e-mail exchange to your requirements document and cross-reference as appropriate.
- Ensure that the main requirements document always shows the most recent version (and keep it as up to date as possible), and that previous revisions are only shown if/when explicitly requested.
answered Apr 10 '14 at 3:44
aroth
8,29812646
1
And you don't work on changes to the requirements until they official documents are updated.
– HLGEM
Apr 10 '14 at 20:19
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
It's really not terribly complicated. You, or your boss, or someone on up the chain needs to assign a project manager to the project. That manager would be responsible for organizing all the requirements, constructing a timeline (and making sure each team is sticking to that timeline), and managing the budget for the project. This manager would be the point man (or woman) for the entire project, and would allow for a central point of organization for the requirements.
In larger firms, project managers are actually job titles, and those people are usually dedicated to doing the above for 1 or a handful of projects. In smaller firms, it may be one person wearing multiple hats as part of the project, one of which reads project manager.
answered Apr 10 '14 at 2:42
panoptical
3,5761538
add a comment |Â
up vote
2
down vote
It's really not terribly complicated. You, or your boss, or someone on up the chain needs to assign a project manager to the project. That manager would be responsible for organizing all the requirements, constructing a timeline (and making sure each team is sticking to that timeline), and managing the budget for the project. This manager would be the point man (or woman) for the entire project, and would allow for a central point of organization for the requirements.
In larger firms, project managers are actually job titles, and those people are usually dedicated to doing the above for 1 or a handful of projects. In smaller firms, it may be one person wearing multiple hats as part of the project, one of which reads project manager.
answered Apr 10 '14 at 2:42
panoptical
3,5761538
add a comment |Â
up vote
2
down vote
up vote
2
down vote
It's really not terribly complicated. You, or your boss, or someone on up the chain needs to assign a project manager to the project. That manager would be responsible for organizing all the requirements, constructing a timeline (and making sure each team is sticking to that timeline), and managing the budget for the project. This manager would be the point man (or woman) for the entire project, and would allow for a central point of organization for the requirements.
In larger firms, project managers are actually job titles, and those people are usually dedicated to doing the above for 1 or a handful of projects. In smaller firms, it may be one person wearing multiple hats as part of the project, one of which reads project manager.
answered Apr 10 '14 at 2:42
panoptical
3,5761538
It's really not terribly complicated. You, or your boss, or someone on up the chain needs to assign a project manager to the project. That manager would be responsible for organizing all the requirements, constructing a timeline (and making sure each team is sticking to that timeline), and managing the budget for the project. This manager would be the point man (or woman) for the entire project, and would allow for a central point of organization for the requirements.
In larger firms, project managers are actually job titles, and those people are usually dedicated to doing the above for 1 or a handful of projects. In smaller firms, it may be one person wearing multiple hats as part of the project, one of which reads project manager.
answered Apr 10 '14 at 2:42
panoptical
3,5761538
answered Apr 10 '14 at 2:42
panoptical
3,5761538
answered Apr 10 '14 at 2:42
panoptical
3,5761538
answered Apr 10 '14 at 2:42
panoptical
3,5761538
3,5761538
add a comment |Â
add a comment |Â
up vote
2
down vote
However the problem is all these requirement clarifications,
discussions summary is in Emails not documented single place and not
updated in original requirement documents.
That is a problem. So why not document the changes somewhere centralized and easily accessible? Does your company run a wiki (or if not, then why not?)?
That's where your requirements documentation should live, and any discussions that happen in relation to the requirements should be attached there. The requirements themselves should be updated in the main document as changes are agreed upon, and each change should be scoped as it is applied to the main requirements document. Your wiki will maintain a log of all changes as they are made, making it easy to view how the requirements have evolved over time. And it can also be configured to notify all members of the development team whenever a change is made, ensuring that everyone is kept informed of changes as they are made.
If your company is not running a wiki, then your immediate task is: Convince your manager(s) that they really, really need to be running a wiki or some comparable solution.
And also due to many changes in the requirements the gap between
initially specified requirements in the requirement document and the
finalized requirements is so high.
Software requirements are never finalized. If the requirements have changed then you really need to update your "finalized" requirements document to reflect the changes. Otherwise you run into exactly the issues you are describing.
If you find it too disruptive to work off of a "living" requirements document (which it certainly can be), you can take a snapshot of the requirements (or some subset of requirements) and call that your Minimum Viable Product. Then your MVP requirements can stay fixed, and that's what you build your initial release towards. Any changes to the requirements are recorded against the main document (or within the product backlog, if you are using agile/Scrum), and you deal with them after completing your MVP implementation.
The problem is not every one who are working for the project on the
same page. And every time I need explain the history how initial
requirements changed to current one. I feel it is not productive and
tedious.
How can I deal with it?
You should:
- Establish a canonical "source of truth" that everyone can use to see the current requirements. A wiki works wonders for this.
- Ensure that information related to the how and why of your changing requirements is documented and accessible from your "source of truth". If a requirement changes because of an e-mail exchange, attach the e-mail exchange to your requirements document and cross-reference as appropriate.
- Ensure that the main requirements document always shows the most recent version (and keep it as up to date as possible), and that previous revisions are only shown if/when explicitly requested.
answered Apr 10 '14 at 3:44
aroth
8,29812646
1
And you don't work on changes to the requirements until they official documents are updated.
– HLGEM
Apr 10 '14 at 20:19
add a comment |Â
up vote
2
down vote
However the problem is all these requirement clarifications,
discussions summary is in Emails not documented single place and not
updated in original requirement documents.
That is a problem. So why not document the changes somewhere centralized and easily accessible? Does your company run a wiki (or if not, then why not?)?
That's where your requirements documentation should live, and any discussions that happen in relation to the requirements should be attached there. The requirements themselves should be updated in the main document as changes are agreed upon, and each change should be scoped as it is applied to the main requirements document. Your wiki will maintain a log of all changes as they are made, making it easy to view how the requirements have evolved over time. And it can also be configured to notify all members of the development team whenever a change is made, ensuring that everyone is kept informed of changes as they are made.
If your company is not running a wiki, then your immediate task is: Convince your manager(s) that they really, really need to be running a wiki or some comparable solution.
And also due to many changes in the requirements the gap between
initially specified requirements in the requirement document and the
finalized requirements is so high.
Software requirements are never finalized. If the requirements have changed then you really need to update your "finalized" requirements document to reflect the changes. Otherwise you run into exactly the issues you are describing.
If you find it too disruptive to work off of a "living" requirements document (which it certainly can be), you can take a snapshot of the requirements (or some subset of requirements) and call that your Minimum Viable Product. Then your MVP requirements can stay fixed, and that's what you build your initial release towards. Any changes to the requirements are recorded against the main document (or within the product backlog, if you are using agile/Scrum), and you deal with them after completing your MVP implementation.
The problem is not every one who are working for the project on the
same page. And every time I need explain the history how initial
requirements changed to current one. I feel it is not productive and
tedious.
How can I deal with it?
You should:
- Establish a canonical "source of truth" that everyone can use to see the current requirements. A wiki works wonders for this.
- Ensure that information related to the how and why of your changing requirements is documented and accessible from your "source of truth". If a requirement changes because of an e-mail exchange, attach the e-mail exchange to your requirements document and cross-reference as appropriate.
- Ensure that the main requirements document always shows the most recent version (and keep it as up to date as possible), and that previous revisions are only shown if/when explicitly requested.
answered Apr 10 '14 at 3:44
aroth
8,29812646
1
And you don't work on changes to the requirements until they official documents are updated.
– HLGEM
Apr 10 '14 at 20:19
add a comment |Â
up vote
2
down vote
up vote
2
down vote
However the problem is all these requirement clarifications,
discussions summary is in Emails not documented single place and not
updated in original requirement documents.
That is a problem. So why not document the changes somewhere centralized and easily accessible? Does your company run a wiki (or if not, then why not?)?
That's where your requirements documentation should live, and any discussions that happen in relation to the requirements should be attached there. The requirements themselves should be updated in the main document as changes are agreed upon, and each change should be scoped as it is applied to the main requirements document. Your wiki will maintain a log of all changes as they are made, making it easy to view how the requirements have evolved over time. And it can also be configured to notify all members of the development team whenever a change is made, ensuring that everyone is kept informed of changes as they are made.
If your company is not running a wiki, then your immediate task is: Convince your manager(s) that they really, really need to be running a wiki or some comparable solution.
And also due to many changes in the requirements the gap between
initially specified requirements in the requirement document and the
finalized requirements is so high.
Software requirements are never finalized. If the requirements have changed then you really need to update your "finalized" requirements document to reflect the changes. Otherwise you run into exactly the issues you are describing.
If you find it too disruptive to work off of a "living" requirements document (which it certainly can be), you can take a snapshot of the requirements (or some subset of requirements) and call that your Minimum Viable Product. Then your MVP requirements can stay fixed, and that's what you build your initial release towards. Any changes to the requirements are recorded against the main document (or within the product backlog, if you are using agile/Scrum), and you deal with them after completing your MVP implementation.
The problem is not every one who are working for the project on the
same page. And every time I need explain the history how initial
requirements changed to current one. I feel it is not productive and
tedious.
How can I deal with it?
You should:
- Establish a canonical "source of truth" that everyone can use to see the current requirements. A wiki works wonders for this.
- Ensure that information related to the how and why of your changing requirements is documented and accessible from your "source of truth". If a requirement changes because of an e-mail exchange, attach the e-mail exchange to your requirements document and cross-reference as appropriate.
- Ensure that the main requirements document always shows the most recent version (and keep it as up to date as possible), and that previous revisions are only shown if/when explicitly requested.
answered Apr 10 '14 at 3:44
aroth
8,29812646
However the problem is all these requirement clarifications,
discussions summary is in Emails not documented single place and not
updated in original requirement documents.
That is a problem. So why not document the changes somewhere centralized and easily accessible? Does your company run a wiki (or if not, then why not?)?
That's where your requirements documentation should live, and any discussions that happen in relation to the requirements should be attached there. The requirements themselves should be updated in the main document as changes are agreed upon, and each change should be scoped as it is applied to the main requirements document. Your wiki will maintain a log of all changes as they are made, making it easy to view how the requirements have evolved over time. And it can also be configured to notify all members of the development team whenever a change is made, ensuring that everyone is kept informed of changes as they are made.
If your company is not running a wiki, then your immediate task is: Convince your manager(s) that they really, really need to be running a wiki or some comparable solution.
And also due to many changes in the requirements the gap between
initially specified requirements in the requirement document and the
finalized requirements is so high.
Software requirements are never finalized. If the requirements have changed then you really need to update your "finalized" requirements document to reflect the changes. Otherwise you run into exactly the issues you are describing.
If you find it too disruptive to work off of a "living" requirements document (which it certainly can be), you can take a snapshot of the requirements (or some subset of requirements) and call that your Minimum Viable Product. Then your MVP requirements can stay fixed, and that's what you build your initial release towards. Any changes to the requirements are recorded against the main document (or within the product backlog, if you are using agile/Scrum), and you deal with them after completing your MVP implementation.
The problem is not every one who are working for the project on the
same page. And every time I need explain the history how initial
requirements changed to current one. I feel it is not productive and
tedious.
How can I deal with it?
You should:
- Establish a canonical "source of truth" that everyone can use to see the current requirements. A wiki works wonders for this.
- Ensure that information related to the how and why of your changing requirements is documented and accessible from your "source of truth". If a requirement changes because of an e-mail exchange, attach the e-mail exchange to your requirements document and cross-reference as appropriate.
- Ensure that the main requirements document always shows the most recent version (and keep it as up to date as possible), and that previous revisions are only shown if/when explicitly requested.
answered Apr 10 '14 at 3:44
aroth
8,29812646
answered Apr 10 '14 at 3:44
aroth
8,29812646
answered Apr 10 '14 at 3:44
aroth
8,29812646
answered Apr 10 '14 at 3:44
aroth
8,29812646
8,29812646
1
And you don't work on changes to the requirements until they official documents are updated.
– HLGEM
Apr 10 '14 at 20:19
add a comment |Â
1
And you don't work on changes to the requirements until they official documents are updated.
– HLGEM
Apr 10 '14 at 20:19
1
1
And you don't work on changes to the requirements until they official documents are updated.
– HLGEM
Apr 10 '14 at 20:19
And you don't work on changes to the requirements until they official documents are updated.
– HLGEM
Apr 10 '14 at 20:19
add a comment |Â
This question appears to be off-topic because it is a question about programming not navigating the workplace.
– IDrinkandIKnowThings
Apr 10 '14 at 4:08
@Chad - I disagree, it's a question on project management, not programming. It just happens to involve a programming project.
– panoptical
Apr 10 '14 at 4:10
OK then it belongs on PM.SE It is not about navigating the workplace
– IDrinkandIKnowThings
Apr 10 '14 at 4:10
That I do agree with (didn't know there was a Project Management SE).
– panoptical
Apr 10 '14 at 4:21
Mmm...fragmentation.
– aroth
Apr 10 '14 at 5:06