So about a week ago some of you gave me advice related to Project Management and how I should interact with my developers.
I work at a company where they are letting my division define the process for getting our work done (we build websites). I have a lead developer, two other developers, and two front-end graphics/programming people on my team.
I am working with the lead developer to create a relationship/flow, but I want to get some input from people who know how to do this (instead of trying to re-invent the wheel).
So I think the process should be like this:
Business Development Manager create a proposal with overarching items or tasks itemized in our proposals with hours or days to complete.
1A) Owner, Project Manager, and Development Lead sign off on proposal or ask for adjustments (hours, wording,etc)
Proposal is signed, Project Manager creates project in Microsoft Project, with those over-arching tasks as categories for developers to report time to.
Project Manager creates PRD (Product Requirement Document/Scope Document)-describing in detail how each item should function-to serve as clarification/road-map for development team.
3A) Client and Development Lead signs off on PRD/adds revisions
Development Lead works with Project Manager to create actual tasks from high-level categories in Microsoft Project/Proposal-these tasks would be the guide for the team to actually develop (far more detailed than a client would see). I am not sure if this part of the project would happen periodically (i.e. I might give the over-arching tasks from the proposal as things to do for the week based on hours, and each week the development lead and I will come up with realistic tasks for the team to do?
4A) PM signs off on tasks, keeps record of list, etc
Team begins to develop according to descriptive PRD and assigned tasks from development lead/project manager
each day team is checked on based on these tasks (budget vs. actual) and the Project Manager updates an evolving form with this data to watch for scope creep, and other risks.
Once all tasks are completed, including QA, the design is given to the client
8)Project is signed off on as complete and we discuss lessons learned (post-mortum reports are created by team, etc)
I know this is general, and I did leave some points out, but can someone comment on my ideas for structure? I am finding that we forget what the client wants, what very non-descriptive items in a proposal mean design/function-wise, etc. I think I might want to build this team relationship with the development lead. This process is based on my own initial experience and conversations with friends in the industry.
The whole thing just makes me weary. Is your staff really such a lot of trained monkeys that their work needs to be checked DAILY against an itemized list?
I would find that insulting, not to mention a waste of time. It also does not permit the employee any control over the order tasks are done (sometimes the order is relevant to sucessful completion, sometimes it is not). Such measures are appropriate only for staff who consistently miss deadlines or turn in incompetant work.
You need to ask yourself if this much process is adding any real value to the project. You’re talking about adding a whole lot of overhead.
Also, you’re missing the fact that software development is not a straight line. You can’t just check of the box saying “widget 1 is done” and expect it to stay that way. Software development is an iterative process; just because widget 1 is done today doesn’t mean that the widget 2 code isn’t going to break it and now it’s not done.
Have you decided on a project management methodology yet (ie, waterfall, agile, etc…?)
The best manager I ever worked with said that the first thing he always did on a project is design the test plan. The worst manager I ever worked with started out by picking the ending date.
It seems rather heavyweight - there’s a lot of overhead there. (e.g. Can you combine your proposal and your scope document/PRD?) Seriously, before we can give any real help, how long and what size of projects are you talking about? Also, you haven’t accounted for the client phoning in change requests.
I’d be concerned that if:
7) Once all tasks are completed, including QA, the design is given to the client.
is the first time the client sees the design, you are going to have the client promptly come back and say that it isn’t what they wanted/asked for and refuse to sign it off. If its in IT showing a prototype and getting UI signed off before going through the entire QA process lowers the risk of doing the whole thing twice.
I am managing a program with about 50 people, and it includes one web development project that is about the same size as what you are talking about in terms of number of people.
How long do these projects last? If they are less than a couple of months then, yes, you do need status daily. Waiting a week to take its temperature can cause unacceptable delays if it takes that long to identify an issue. During development my tech lead conducted a daily stand-up meeting to raise issues that could impact schedule (however, it was not a run-through of a list of tasks). Nobody was allowed to sit down, that keeps it short. It gave him a great feedback loop because the tendency of some developers is to sit on a problem and underestimate its impact until they are explicitly asked a question.
If they are more than a couple of months then daily status is probably overkill but you still want to encourage frequent interaction.
Otherwise your process is the textbook method for controlling projects and the way I’ve been doing it in federal contracting for decades. However, some companies and situations may not need that level of rigor.
Wouldn’t it be more useful to identify the requirements first? :dubious:
Theoretically that is indeed a terrible way to start. However, welcome to the real world of project management. IME the project manager rarely gets a vote on the end date. One of two things, or both, often happens:
The client tells you when they need it. You exist to serve the client so if you can’t do it they will find someone else who can. I have also seen a couple of situations where, internal to a company, the business unit does not like what the in-house development group is willing to promise, so they hire someone from outside who will tell them what they want to hear. (Unfortunately this results in a lot of consulting companies over-promising to win work.)
One group writes the proposal, the purpose of which is to win work. At proposal time you have only the highest-level idea of what the requirements really are. Then the PM, who is not always on the proposal team, has to live with it.
You mention task and item tracking in very small time scales. While it is ok (and often necessary) to have small tasks identified and flowed in a project schedule, tracking them individually for status is a huge overhead and brings very little value to a project. I have literally had projects where all of Monday was spent keeping key people in meetings “stoplight” tracking hundreds of items from the previous week, for reports to be printed the next day and to be distributed on Wednesday when they were already out-of-date, when really what was needed was to just get shit done–it was a massive drain on productivity.
I take a “scalability” approach to tracking. When just status-collecting starts taking more than a few hours a week, start milestoning your timeline and push the smaller tasks down.
Also, initial specifications as approved by the client almost never end up aligning with their end-result perceived expectation of the product. Think of a television commercial where the initial spec is described in text and storyboards, and the end result is filled with sound, graphics, music, acting…there are now a million assumptions that have been made between initial approval and delivery that the client could say “hey man, we didn’t want that! That’s not what we meant by ‘jazzy’!”
Have the client involved regularly, at all milestone decisions, so any deviations or creep can be justified, documented and agreed to. I’d recommend meeting formally (i.e. donuts and gifts of coffee mugs with company logo ;)) with the client as often as your budget can allow.
Well, in spite of what Shodun said, sometimes externalities set your project end date for you.
Scoping to the individual task level id fine for planning and budgeting but you shouldn’t need to checkpoint with your team daily. Weekly milestones should be fine.
Years ago I worked on a develpment project of 30 people. Our PM had a high level, mid level and 14 day project plan. Every day we had to fill out a 14 day grid on a whiteboard with our tasks. Every day the team met at 9:00am so every single developer could discuss how we were tracking to the 14 day plan. Every few hours we had to checkpoint and have follow-up checkpoints. I wouldn’t even start developing until 4:00 in the afternoon!!
