Talk:Integrated Design Process (IDP)

From apppm
Revision as of 14:08, 19 February 2018 by DemirDurovic (Talk | contribs)

Jump to: navigation, search

Contents

Abstract Feedback

Text clarity Difficult to follow at times. Consider using more short and concise sentences

Language Some minor spelling mistakes

Description of the tool/theory/concept Easy to follow

Purpose explanation Elaborate on the purpose of the article - what will the reader get out of this/learn? Are you looking at the bidding/tender phase of finding a supplier/design team for a construction project? This needs to be defined. Briefly explain the structure of the article in the abstract to set reader expectations

References Good, try adding more references to the mandatory list of references where appropriate

Relevance of article Consider the following:

  1. Who is the reader? Project Manager or Sponsor etc?
  2. Add more context around project management
  3. Ensure depth of the article so it contributes to the project management community more than a normal web search


Feedback 1 | Reviewer name: Demir Durovic'

Question 1 · TEXT

Quality of the summary:

Does the summary make the key focus, insights and/or contribution of the article clear?

What would you suggest to improve?

Answer 1

The language is acceptable and understandable; it has Minor spelling mistakes, which should be fixed before final handin. The abstract explains really nice what your method is, and why it is relevant, but it should also include how and why it relates to project/program/portfolio management since this contribution is about your specific method and how it works according to projects/Portfolios/programs. Maybe try and find a specific, short and precise connection in the material we have been given, and use it in your abstract. You abstract can maybe be a bit longer, and it is clear that your abstract is divided into micro sections with different information, and these sections are not very well connected. You should consider to have a connection to all your information in the abstract otherwise it will just look like a lot of small individual statements. When you have these small independent statements it makes is difficult to identify who the reader of this article should be.

Question 2 · TEXT

Structure and logic of the article:

Is the argument clear?

Is there a logical flow to the article?

Does one part build upon the other?

Is the article consistent in its argument and free of contradictions?

What would you suggest to improve?

Answer 2

It is good that you build up with some theory and methodology and actually connects it with projects and programs. It has good natural flow and it becomes a bit more clear who the receiver of the article is. I would "backward integrate" here and use some of the good parts you have written in you abstract, since the sum up in the beginning should demonstrate what the content of your article is, and therefore you need a closer link to project and program management in you abstract. It is consistent and there are no contradictions so far. The arguments for why it is important and where it is used are good. It shows with relevant referencing why and how it is applicable. The overall flow is decent, and it looks like what you have planned to write will follow a nice similar pattern. Just remember to focus on having a core if the most important information, which is super simple, and then you can apply and put more information on it; Having a small scope when you write it now, and then expanding it later and add to it

Question 3 · TEXT

Grammar and style:

Is the writing free of grammatical and spelling errors?

Is the language precise without unnecessary fill words?

What would you suggest to improve?

Answer 3

After your abstract you have some sections with some good parts, but in general the level of your language level drops a bit. You should consider reading it through one more time and remove spelling mistakes. You don't necessarily have fill words, but formulations like: "IDP done successfully identifies slippage and problems before the production phase... " is not the best formulation. You could write: "When the IDP method is executed correctly it can identify potential problems before the production phase....". Obviously we don't want fill words, but removing words for the sake of it has the same negative impact as unnecessary fill words. I will suggest you go through your whole article several times when you are done, and read it out loud. It will make it easier to find spelling mistakes, grammar mistakes and "bad" formulations.

Question 4 · TEXT

Figures and tables:

Are figures and tables clear?

Do they summarize the key points of the article in a meaningful way?

What would you suggest to improve?

Answer 4

There is one figure, and it is difficult to see what the figure represents. Find a similar one with a higher resolution. You don't refer to your figure, and it is located between two sections, so i have some issues pinpointing why you have it, unless you plan to use it later. If you don't plan to use it later, then refer directly to it in what you have now, and write why it is in the article, otherwise just remove it. Rather have 0 figures than 10 unnecessary ones.'

Question 5 · TEXT

Interest and relevance:

Is the article of high practical and / or academic relevance?

Is it made clear in the article why / how it is relevant?

What would you suggest to improve?

Answer 5

You do mention how and where it is used, and also what benefits it can add. You should, when you write about applicability later

Question 6 · TEXT

Depth of treatment:

Is the article interesting for a practitioner or academic to read?

Does it make a significant contribution beyond a cursory web search?

What would you suggest to improve?

Answer 6

Answer here

Question 7 · TEXT

Annotated bibliography:

Does the article properly cite and acknowledge previous work?

Does it briefly summarize the key references at the end of the article?

Is it based on empirical data instead of opinion?

What would you suggest to improve?

Answer 7

Answer here

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox