October 9, 2008 at 7:56 am
I agree with the last sentence in the editorial that project managers need to coordinate issues and then get out of the way. PM is a full time job on medium to large projects, and it allows the architects, analysts, and developers to stay focused on their own issues. I would never advocate eliminating a PM except on the smallest projects.
I do believe in documentation, but not detailed specs since those change so much over the development lifecycle. Initially, a business requirements/deliverables doc is needed to get things going. It will be tweaked over time, and those tweaks need to be tracked, but the dev team just needs to know what the target is (I'm assuming there is already a development standards doc in place). Use case scenarios can also be developed, especially if procedural/training docs are needed later.
At the end, a configuration and business rules document is needed once the project is complete so people know how the system works, why things happen the way they do, etc. (i.e. revenue is calculated this way, you can change the DB connect string by editing this file, etc.). I find that if the requirements doc is well done and maintained, much of it can be copied directly to the final business rules doc which saves time.
If training docs, end user procedures, etc. are also needed, that is a separate deal and need to wait for the system to be finalized anyway.
J Pratt
October 9, 2008 at 9:06 am
For the past 3 years my job title has been 'Technical Project Manager'. I'm also a registered PRINCE2 practitioner (for those who don't know PRINCE stands for PRoject management IN a Controlled Environment and is the UK standard for project management).
I've worked on several projects and agree with Chris Harshman that Project Management should be used to facilitate the progress of the project, but all too often it just becomes bureuacracy.
In fact, having had proper training on using MS Project and knowing the principles of PM, I've found that spending a couple of hours (days?) drawing up a plan (including a Gantt Chart) and then using it - even for my own 'quick' projects of a couple of weeks - actually helps to keep tasks in focus and allow me to easily report to my management on whether the project is on track or not (and why). A quick verbal "I'm about 45% done and reckon I'm half a day ahead" is a perfectly good status report - it doesn't have to be a 10-page document with abstracts, circulations lists, signoffs and all the other junk.
What it all comes down to, as PRINCE2 points out, is that planning underlies any project and you should always be prepared to revise the project plan in the light of progress. Where many projects fail is that the project management process becomes an end in itself and people aren't prepared to revise things and go back to higher management and say "this estimate was wrong"!
I'd vote for having a properly managed project every time. What I don't want is to be forced to use a PM methodology where filing the weekly status report in the prescribed format is more important than actually doing the work!
Derek
October 9, 2008 at 9:25 am
I've always seen my role as a technical manager/project manager is to a) understand the goals and specifications of the project, b) translate those into technical needs, and, most importantly, c) make sure staff have to tools and resources to successfully complete the project.
Item (c) involves a lot of interference running and administrative tasks that should not be shoved off on the folks doing the primary work. This does not mean that you don't keep staff in the loop. In fact, I like for staff to know where I obtain resources and more importantly from whom I obtained them. It's important to stay networked and to help staff to get networked. A "plugged in" staff are better able to pursue issues independently (when necessary) and have better career opportunities later in their tenure.
Conversely, the PM has to understand the nuts and bolts of the project to be able to translate broader specifications and objectives into a productive technical framework. I get to have less fun now (i.e., less coding and development) but it is satisfying to work with many groups to jointly tackle large projects. It is doubly satisfying to give staff the opportunity to excel and to publicly brag on their efforts and talents at the successful conclusion of the project.
Our group is not very formal and very open and fluid. We try to keep everyone involved in the project "cross-aware" of each other's tasks without getting in each other's way. As for charts and workflow, timelines, etc., I typically disdain them except for things like ERDs and important process flows. I'm sure the PMBOK folks don't like this but I find these exercises generate as much work as they prevent.
We do track hours spent on projects but we built a SQL-based application that is fairly simple and takes very little time - perhaps a couple minutes a day to enter time.
Cheers.
October 9, 2008 at 9:49 am
In previous lives when I actually managed people, budgets and projects, I had all of my prospective team mates read, agree to and sign a framed copy of the Agile Manifesto (http://www.agilemanifesto.org/). The signed manifesto hung in it's frame on the team wall with the burn down chart, etc.
Back before Agile Process™ were cool, we just borrowed whatever worked from various methodologies: pair when it makes sense, unit test as much as possible, continuously integrate with every check-in, have impromptu stand-ups when necessary instead of email threads longer than 3 replies deep, etc. Gantt charts are useful upon occasion, although not enough to keep them evergreen, and we only produced them when required for a presentation to the Bored Directors™ and Vulture Capitalists™.
The goal of producing Working Software™ every day/week/month/year that users could use and validate really helped to keep us focused instead of wandering off into Science Fair Project™ land and the scary Kingdom of PMBOK.
The metric that mattered the most for me and my teams was "Did the customers try the feature and sign off on the story card this week?"
October 9, 2008 at 9:53 am
I also agree with the last sentence in the editorial that project managers need to coordinate issues and then get out of the way.
Working in a small company a formal PM plan is often not needed, but some plan/specs should be in place to help identify the the goal and it's parts and identify any stardards necessary.
Without one, it would be like building a house without blueprints. How could you estimate or evalute the costs (time, materials) and to what standard. Would all the door sizes be diferent, would there be a roof, and would it even be inhabitable?
-- Optimist with experience and still learning
October 9, 2008 at 10:01 am
I am a PMP and ex-coder/team lead and currently a BA/Systems Analyst/project manager (and occasional coder when needed to help out). Similar to the author's wife's experience, I never conciously use what I learned when studying for the PMP exam.
I completely agree with the notion that the tools\techniques, etc. applied should be "appropriate" for the problem at hand. What's "appropriate" is a matter of judgement that takes a number of factors into account - size of the problem/solution/team, team member skills and locations, relationship with and expectations of the customer, resource availablity, regulatory requirements, schedule constraints, etc. Judgement is derived from experience, so it never surprises me when I see projects in trouble where the PM just got out of B School or otherwise has little domain experience.
As to documentation, I always ask developers to make an informal design document that's scope appropriate. This usually boils down to a simple description of the interfaces and other key design considerations and for our mini projects rarely exceeds one page. This is my personal bias as I find that when I write this stuff down it sharpens my thinking, and it's good to vet with someone in a brief meeting. I have never not had feedback when reviewing these documents with my developers and the design often changes quite dramatically as a result. And it helps a lot in guesstimating the effort involved and managing how things are going against the expected design. Other than that good comments in the code and some meta data in the database is about it, except for maybe a problem statement if the problem's big enough and/or poorly defined. Some sort of schedule is usually required by the client I always pitch that to the client as flexible and that as we learn more it will probably change, ala McConnell's "Cone of Uncertainty" concept.
I like the idea of SCRUM. Although I have yet to use it, it seems pretty practical and scalable.
October 9, 2008 at 11:30 am
Phil Factor (10/9/2008)
The Blob analogy...
Awesome metaphorical pictures Phil! Thank you!
October 10, 2008 at 9:59 am
Phil Factor (10/9/2008)
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.
I use project documentation as a tool for tracking the configuration of the work. Let me use a project from a couple of years ago as an example, without going into too much detail:
We needed to create a product that would fill a need of the military, but they had only a very general idea of what they wanted, so we had to create our own requirements list before we could begin to design and build the equipment. The first couple of weeks we scheduled one to two hour sessions twice a day to brainstorm on what we thought the grunt would want this equipment to do. I captured the discussion in notes, and between meetings wrote up what we had discussed into a draft list requirements. While I was doing that, the rest of the team investigated the best choices for hardware, components, and software tools, and used information from the discussion to start drafting a system architecture. When we reconvened I went over the list I had developed and got buy in from the rest of the team.
As we went along we discussed each part of the architecture and decided what its performance characteristics needed to be. Eventually all my notes became the first draft of a requirements spec defining capabilities, which was reviewed by the team and augmented with specific hardware or software functions.
We repeated this pattern with the design document, which we modified as we got smarter on how to implement the product, adding later sections capturing the detailed design. In this way it was relatively simple for me to extract the information I needed for customer and management reports without needing to bother the technical team too much while they worked. The biggest role I played in the design was in listening to alternatives for solutions by team members and helping them talk through the advantages and disadvantages until the team consensus on the better choice became clear.
As far as Gantt charts go, I created a top level one because it was required by the contract, and I added more detail as we defined the system because it helped me better understand the maturing product. It also made it apparent when we had forgotten some steps (such as needing a second prototype when the first design was shown to be flawed), so I learned how to ask better questions on the next project.
October 10, 2008 at 10:04 am
Ewan Hampson (10/9/2008)
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).
I totally agree with this comment. The biggest challenge is to provide the necessary information to upper management so they don't try to "help" too much.
I would also say that PM activities, while not appearing to contribute too much to the work progress, is very necessary for big programs, like designing a new aircraft. Coordination is required to integrate the efforts of various teams and usually thousands of people to produce such a complex end product.
October 10, 2008 at 10:10 am
Ed Salva (10/9/2008)
I also agree with the last sentence in the editorial that project managers need to coordinate issues and then get out of the way.Working in a small company a formal PM plan is often not needed, but some plan/specs should be in place to help identify the the goal and it's parts and identify any stardards necessary.
Without one, it would be like building a house without blueprints. How could you estimate or evalute the costs (time, materials) and to what standard. Would all the door sizes be diferent, would there be a roof, and would it even be inhabitable?
Interesting that you would use that analogy. I bought an old house and a few years later a window got broken. I called a local glass shop and he asked how big the window was. I said I didn't know exactly but it seemed like a standard size window. He sighed and said "there are no standard windows".
October 10, 2008 at 10:38 am
Windows are fun. Cabinet doors are better with the trim. Need to replace one of those this weekend.
October 10, 2008 at 11:07 am
" He sighed and said "there are no standard windows". "
This is so true, but I'll bet the doors and windows within the house have a similar look and feel.
I was forturnate to have an 80 year old house where the windows were a consistent size and were between 1/16 and 1/4" out plumb.
This made replacements about as easy as you can get.
-- Optimist with experience and still learning
January 10, 2011 at 10:13 am
Afternoon all,
What interests me about Project Management is quality of being able to management human resources to highest standards. Projects fail because of inadequacies in people management. I’ve seen these real life scenarios where you can easily detect where something will go goring based on delegate’s attitude. That’s why I would say, in most cases, where training in concerned, to for a Prince2 training as the framework applied here means all who are involved in project know exactly what they are doing and required of them. By improving the skills and thinking processes of your workforce greater ROI can be generated for organisation. In particular, I would add that theoretical jargon sometimes just doesn’t cut to the chase rather what’s needed is more demonstrative learning, I think all the reflectors will agree to that, of course your constructive criticisms are welcomed.
Kind regards,
Sam Colisson
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply