October 8, 2008 at 1:02 pm
Comments posted to this topic are about the item Project Management Management
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
October 8, 2008 at 9:43 pm
Project management is necessary especially for big projects. Of course a good project manager makes a big differences. A good project manager helps to co-ordinate people from different departments to work on the same project. Most of the time an IT project involves in a lot of other departments to gather information and data. One of the tasks of the project manager is involving and motivating all the departments together to finish a project for the company.
October 8, 2008 at 11:37 pm
I have been working in development and project management on and of for a number of years. Every project where I have been in charge has been successful. And I think it's down to the basic idea that a project, and the relationship with the customer (important one this), is a little bit like the 1957 film The Blob. It's cumbersome, moves slowly, eats you alive if you get in it's path, it's dustructive and ties up resources etc. A project manager will never completely control the blob, instead his role is to nudge and guide the Blob to the ultimate goal. There will always be parts of the Blob that try to escape, and that's where a bit of aggression is required. But never lose sight of the goal.
And I agree with a lack of flowcharts, specs etc. I have always instead produced documentation that covers what is going to be delivered, not the interpretation is of a customer's spec. Interestingly, customers are able to deal more easily with concrete ideas for the solution rather than theoretical ideas of the problem, and a meeting of minds is achieved so much earlier in the process.
And the 1980's version of the Blob was so much faster.
October 9, 2008 at 12:05 am
Totally agreed! The way of a project management depends on the people selected.
The methods in project management books like just open source code requiring tweak accordingly before reusable.
October 9, 2008 at 2:37 am
The Blob analogy is a good one. I always wondered why that film terrified me so much. Actually I think that there are two blobs. The project itself , and the relationship with the customer is one blob, and ones own management is the other blob. The second blob has its own expectations and anxieties about the project and can meddle with what one is doing, particularly if you are doing radical things they don't understand, such as eschewing Gantt charts and other ritual symbols, working with the team members, and monitoring the real project pain-points.
I always create a third Blob, of project documentation. For this, project management software is ideal, as it can be persuaded to churn out paperwork in enormous quantities. It bears little relationship to what is happening in the real world but it really doesn't have to. The Management Blob is instantly attracted to the Documentation Blob and, after a brief struggle, retires demoralized to lick its wounds.
In the corporate world, projects have to be done by stealth and deception if they are to succeed. Project Management Software is excellent at providing the essential smokescreen for a project.
Best wishes,
Phil Factor
October 9, 2008 at 2:57 am
Echoing Phil's comments, I'd say that much of the formality of project management is about keeping higher management happy and persuaded that things are happening and on track, rather than actually aiding those involved in the dirty work. (Especially Lessons Learned - every project closure I attend seems to be "learning" those same lessons...)
But I do think PM really matters for small and scattered teams. 3 or 4 people working at separate sites may have the right skills and domain-specific knowledge to do the work. But if no-one is nominated to identify and interact with the stakeholders (I hate the word, but the meaning is useful) and to sustain the support of higher management, wider issues can be missed (because the experts focus on the details), and roll-out can become difficult (because no-one is bringing the users along).
October 9, 2008 at 2:58 am
I'm with a team building a new huge system which I can not talk about.
However, we're using a project method named SCRUM.
I can only say that this far, been going on for many month now, SCRUM is one very effective good method that for us has been very successful.
You should read about SCRUM and see if it's something that you might consider. I was surprised how well this method works. It's a method that has tried to take advantage and turned old method around and gives them new concepts around with some new idés and the nice part it's been used by several now with good success.
October 9, 2008 at 5:08 am
I am also with the 'looser style'....
For a technical guy like me if a 'decent' time is given with less monitoring there is a huge difference in the productivity as well as quality of outcome.
I see a project manager who updates the progress to the 'client'.
How he convince the client is again depends on the person.
October 9, 2008 at 6:06 am
Like Steve said, the people you have on the project is the thing that determines how successful it is. However, at my last job, we had 2 project managers with differing styles. One kept things loose, she kept management out of our hair, dealt with the project sponsor, helped us gather requirements, etc. She basically handled as much of the overhead as possible so we could do work. The other one preferred to get involved in the details as much as possible and was very strict with procedures and documentation, etc. He basically tried to get in the way even more (as well as made poor technical decisions and chewed out developers in public).
Guess which project manager was successful? The one who dealt with the overhead instead of adding to it. She was vastly more successful. Both of them had a big project at the same time, the poor manager's project was a catastrophe, the good manager's project was decisively successful despite massive cuts to the timeline.
October 9, 2008 at 6:21 am
Like many aspects of the computer field, project management is evolving. There are a lot of tools and methodologies, not all of which work for all situations. The bigger the project, the more you need project management. For small projects, it may be perfectly legimate to put a small team together and just say, "hey, you guys take care of this." For larger projects, obviously you need central coordination.
Also like many aspects of the computer field, project management can become a religion. I appreciate Steve's comments involving things like Gant charts; sometimes they're helpful, sometimes they're not. I've been on projects where the leaders were very enamored with a certain methodology, even when it was becoming sadly apparent that the methodology was getting in the way more than helping.
I worked for one company where they thought so highly of project management that they had 3 PMs when I came on board even though at the time I was the only on-site developer. We had a small team of overseas developers, but no one really understood what they were doing. They definitely weren't be "managed" by the PMs or anyone else. Upper management didn't see any disconnect between the number of managers vs the number of people actually working.
___________________________________________________
“Politicians are like diapers. They both need changing regularly and for the same reason.”
October 9, 2008 at 6:40 am
Gant charts; sometimes they're helpful, sometimes they're not
I've always thought Gantt charts are a sort of shorthand for "this must be a well-managed project because it's got Gantt charts".
True, their content is comprehensible in the most superficial respect by people who have no PM training; and, of course, they can be faked up in Excel by people who have no PM software. But they are of very limited use - too long a span and too many tasks and they are unreadable.
Most (I assume) PM software is clever at handling scheduling and dependencies and resource planning, but most PMs I have met are not good at using it, and no good at all at helping others understand. Without a common language things get reduced to grunts and whistles - and Gantt charts.
October 9, 2008 at 7:17 am
37Signals had a great disdain for Gantt charts and in the talk by Jason Fried, he actually stopped and spent 4 or 5 minutes saying why they're so bad. They're a complete abstraction for people's time, and they don't represent what's happening in his experience. So he won't ever build them.
I tend to agree since every time I've been asked to do one or work with one, it's a time sink and I constantly have to work with it to get it to come close to reality.
Now there are some places I've seen them work well. At the nuke plant, with hundreds of people planned for tasks during a refueling, they helped. There were 10 or 15 people dedicated to updating and monitoring the large gantt chart (about 8 ft tall x 20 ft wide) on the wall and getting tasks ready, but that was for a highly compressed 2 week period of work where you have to literally do some things in a series and there are all kinds of dependencies. without visualization, no one could effectively track the work. Or prove it was done correctly, which is kind of important in that environment.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
October 9, 2008 at 7:19 am
I've been a database professional for over 15 years now, at a variety of companies both as an in house developer and in a contractor/consultant role. The problem I've seen hapen over and over again with project management is that some companies adopt project managment as a bureaucracy instead of a methodology.
Project management isn't about generating vision scopes, requirements documents, gant charts, etc, it is about leadership, communication, and organization. Each one of those documents does have a purpose toward one of those 3 goals, but they are just tools to achieving those goals not goals themselves. So many companies seem to robotically go through the motions of having meetings, writing these documents, and then declaring that they are doing good project management yet the actual project teams struggle to make progress or members don't even know what's going on. The most effective project manages that I've seen use these tools sparingly, but focus more on ensuring the right people get the right information in a timely manner in order to work towards the right goals. We need more enlightened project managers like these! 😀
October 9, 2008 at 7:31 am
project managment as a bureaucracy instead of a methodology
Now there's a dissertation waiting to be written. Sounds like an anti-pattern.
I agree. Maybe a "good PM" simply has the same qualities as a "good manager", in a particular role and situation.
October 9, 2008 at 7:49 am
Ewan Hampson (10/9/2008)
project managment as a bureaucracy instead of a methodology
Now there's a dissertation waiting to be written. Sounds like an anti-pattern.
I agree. Maybe a "good PM" simply has the same qualities as a "good manager", in a particular role and situation.
I've always found it interesting when companies spend large dollars investing in project management classes for their current management. New management is something else (employees new to management) but you would hope that existing managers already know how to manage projects in some sense, or you should probably demote them.
Not that this has anything to do with reality.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
Viewing 15 posts - 1 through 15 (of 27 total)
You must be logged in to reply to this topic. Login to reply