• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Progression towards Project Management...

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

    #51
    Top thread

    Agree - very impressive responses by some really good PMs. Like most of you, I have been 'indoctrinated' in the Prince2 dogma, however I can see it's not a silver bullet and things can be done equally without it. On the other hand, most banking projects are done on the hoof, with min emphasis on documentation and processes and the only criterion is whether the implementation has been successful or not. IMO you can still hold your head high even if you have PM'd a project that hasn't delivered but you have documented/highlighted the reasons why (eg lack of time/money/resources/etc) This can be done at a later date avoiding a repeat of duplicating whole stages - I have picked up several projects that could have saved half the time/money rewriting/going over most of them
    - for me this is where Prince2 wins over Agile etc.
    Last edited by Dow Jones; 24 April 2008, 12:20.

    Comment


      #52
      Originally posted by Dow Jones View Post
      IMO you can still hold your head high even if you have PM'd a project that hasn't delivered but you have documented/highlighted the reasons why....
      However, I suggest leaving them off your CV might be a prudent move....

      Comment


        #53
        Originally posted by Dow Jones View Post
        IMO you can still hold your head high even if you have PM'd a project that hasn't delivered but you have documented/highlighted the reasons why
        Especially if you forecasted the calamity and warned them before the fact. Takes some juggling between Risk Management and assessing progress.

        They don't always want to hear it though, do they!
        When you encounter speed humps, sound your horn in protest.

        Comment


          #54
          I agree that this has been a good thread because it had open and honest opinions and experiences being expressed.

          In this industry openness and honesty is rare but that is understandable. IT (and embedded - my thing) as a discipline is still under development. We all have found people that know stuff we didn't and vice versa.

          The key to a successful dev project is to get everyone on the same page and that's what Agile is attempting to do by keeping everyone informed, pair programming etc. If you get a good PM who says he isn't Agile then he's doing the fundamentals of Agile naturally.

          Comment


            #55
            the company I currently contract for use a methodolgy called
            Succesful Project Managment - which is quite a catchy name

            I had not heard of this before and assumed it was an in house methodolgy (it is a big company!) however a quick google found me this link

            Which seems to be quite a good methodolgy for the vast majortiy of projects I have worked on - it concentrates on the people and not the paperwork

            for example right now I am rolling out a new system to about 600 branches - and so all the admin teams and managers in these branches need to learn how to use the system and also accept the changes the system will cause to their jobs.

            So the key to the success of this project is not highly technical documents detailing PC specs and how we are going to connect these PC's to the network (from what the network team have told me as long as the branches have an adsl line and they know the username of the user they can roll pretty much anything out to them - and this has been true for the first 4 phases of the 6 phase roll out plan)

            The key is actually winning the hearts and minds of the operational teams to ensure they use the system properly and understand the benefits the system offers.

            Comment


              #56
              Group hug?



              I know this could be construed as taking the mick but I'm not.

              I could do with some useful input into http://forums.contractoruk.com/techn...using-git.html if anyone's interested.

              It's a reasonably relevant subject I think.
              Last edited by Maca; 24 April 2008, 12:49.

              Comment


                #57
                I heartily agree with beercohol...and agree this is a great discussion. For my sins I'm a current PMP, was also in a gig a while back that was exclusively Prince 2 so I'm very familiar with that beast to, though not certified - and have an MBA with a focus on Project Management. So I've just about got the theory bit under my belt....I've also been doing the job for over 10 years.

                What I would say that the biggest failing I've seen from fellow PMs (and I've also taken on projects that have been failing so I've seen a few of them!), is focusing too much on the "how" rather than the "what" and "when". Having a methodology you work to is a double edged sword...the danger is that you become overly focussed on the mechanics of the thing, and forget what you're there for - and before you know it you're missing deadlines or breaking things. On the other hand though, having a methodology helps you not miss such things.

                I guess having a set of PM tools such as PMBOK or Prince 2 is all about knowing when and how to use them. A bit like being an expert at an overhead kick in football...great at the right time if you can do it, but you look a compete dork if you do it all the time
                Is God willing to prevent evil, but not able? Then he is not omnipotent. Is he able, but not willing? Then he is malevolent. Is he both able and willing? Then whence cometh evil? Is he neither able nor willing? Then why call him God? - Epicurus

                Comment


                  #58
                  Project Management

                  Being a PM is undoubtedly as difficult as being a developer. The challenges are juggling the demands of the customer, dealing with a schedule which often has been driven by the sales team and keeping the development team focussed on the end game.

                  To be a good PM, I believe that you need:-

                  1. A thick skin
                  2. Powers of persuasion
                  3. Ability to listen to all parties
                  4. Knowledge of what's required to achieve the goal
                  5. Organisational skills
                  6. A logical mind

                  Ex-Developers could make bad PMs as typically they have little experience with requirements 1,2 & 3. Equally there are plenty of PMs who are very good at items 1,2 & 3 but have no ability in items 4,5 & 6.

                  I believe that demonstrably good business analysts/architects could have the necessary skillset to cover all 6 requirements.

                  Unfortunately, there are many bad PMs out there which give Project Management in general a bad rap.

                  Comment


                    #59
                    Originally posted by mace View Post
                    Being a PM is undoubtedly as difficult as being a developer. The challenges are juggling the demands of the customer, dealing with a schedule which often has been driven by the sales team and keeping the development team focussed on the end game.

                    To be a good PM, I believe that you need:-

                    1. A thick skin
                    2. Powers of persuasion
                    3. Ability to listen to all parties
                    4. Knowledge of what's required to achieve the goal
                    5. Organisational skills
                    6. A logical mind

                    Ex-Developers could make bad PMs as typically they have little experience with requirements 1,2 & 3. Equally there are plenty of PMs who are very good at items 1,2 & 3 but have no ability in items 4,5 & 6.

                    I believe that demonstrably good business analysts/architects could have the necessary skillset to cover all 6 requirements.

                    Unfortunately, there are many bad PMs out there which give Project Management in general a bad rap.
                    Actually I'd go a little further. In my experience the really effective PMs come out of Operations/Support environments, not development. Mainly because they have grown up with multiple concurrent and often conflicting demands, whereas a good programmer is mostly working linearly on a single piece of work.
                    Blog? What blog...?

                    Comment

                    Working...
                    X