Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Project Management: Expectations Set = Expectations Met

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Project Management: Expectations Set = Expectations Met

    ** This thread discusses the article: Project Management: Expectations Set = Expectations Met **
    ** This thread discusses the Content article: Project Management: Expectations Set = Expectations Met **
    0

  • #2
    Project Management: Expectations Set = Expectations Met

    ** This thread discusses the article: Project Management: Expectations Set = Expectations Met **
    I was about as disappointed with this article as I would be had MC Press published a piece on how to use matching records. While Steve Collins does make some casual allusions to managing change and hints at more agile methods in the section on project meetings, he seems to be espousing a very large, unwieldy mastadon that long ago lost its place in modern development stategies. Please don't let Scott Ambler see this article - he'd drop dead in place.

    Comment


    • #3
      Project Management: Expectations Set = Expectations Met

      ** This thread discusses the article: Project Management: Expectations Set = Expectations Met **
      I've had the chance to see both sides of project management, first as a longtimePM and in the last 2 years as a sponsor of IT projects for a Finance division. This article hits home for me in several ways. Too many project managers, including me at first, set expectations well but don't adapt to change or fail to control it. Very entertaining article. I'd like to see more detail in future articles. - JB

      Comment


      • #4
        Project Management: Expectations Set = Expectations Met

        ** This thread discusses the article: Project Management: Expectations Set = Expectations Met **
        Thing is, as a one-man shop, I do a lot of these things without formalities. But it is good to have a "reference chart" like the table in the third formal methodology listed. But I like projects in pieces, because there are multiple things going on all the time. Take each project requirement, first break it down into possibly discrete steps, whether the steps are dependent on each other or not, or possibly independent. Say a new requirement needs some kind of text manipulation, and you know more similar requests are coming, or "they always do". So break out the functionality that will be needed again, make it a separate project, and you have two things instead of one! Sounds like more, but it has made my life better.

        Comment

        Working...
        X