I am junior project manager for a small division of our website company. We develop websites and software for external clients.
Unfortunately the previous project manager quit, and the other team has not been too available for incite, so I am left to help my team out and keep everything moving.
What I started to do was divy out the tasks via to-do lists and have everyone report their status/how long they took/etc with them.
The problem is the team does not know what they should be doing without constant interaction with me, which causes overhead and wasted time.
The result is people either come to me to find out what to do, or they just spend excessive amounts of time on particular parts of a project and kill the budget.
Should I create a SCRUM model, where I divy the website tasks up into workflows (one for the graphics guy) (one for each developer, etc)? These workflows would list the tasks, include documentation to describe how each task should look, and the amount of time each task has for completion?
I would imagine this would give someone a project-based to-do list, and they could report their progress quickly in a 15-minute daily meeting so I can track how we’re doing.
Is that a better way to do it? Can someone help me? I feel as though I am expected to get us pumping out things on time, but without any direction.
Daily meetings might be okay for a couple of weeks until you get a handle on what’s going on and your devs get a feel for the workflow, but you run the risk of folks becoming very irritated with you.
I’d stick to M W F, T H, M W F for a half hour for the first three weeks, and then a weekly, hour-long meeting on Friday after that.
If people are running out of things to do or spending too much time on particular tasks, then the budget probably needs to be revised.
So: start with your spec. Divide the work in to functional areas. If you’re running a small team, have individual meetings with each member where you nail down the dependencies and more realistic estimates.
Don’t start pushing particular development models until you have an idea of what the actual job looks like.
He apparently did not do it well-they had the same issue.
I am just afraid of our budgets being eaten. With several people working on a project it can lose a ton of hours daily.
So I should suggest a change order to a client?
Yeah, I usually like to have a meeting to introduce the tasks to the individuals then let them run with it, but we have tons of projects so it sometimes requires a few of them for each guy.
I am thinking if we get these to-do’s into workflows they might have a digital guide instead of a physical to-do list.
yeah, it’s just the SCRUM model sounded like what I was doing myself (having a bank of tasks, creating to-do lists, and having the team report on it).
Based on this, the first thing that comes to mind is that the tasks your assigning are NOT well defined. There is too much not defined, so your developers come to you for the rest of the information. Similarly, if they are spending excessive amounts of time on only parts, then the “completion criteria” is also not well defined.
As smart as developers are, with a big project made up of lots of smaller tasks, having a clear understanding of each task (which includes knowing when it is complete) is KEY. It will SAVE YOU TIME IN THE LONG RUN to take the time to define/describe/brain dump all that you can about the individual tasks. Just because you have a good sense of what the tasks are (and it can be assumed this is true since they all go to you to get the answers), doesn’t mean the developers can “infer” the same level of detail. Spell it out for them.
Next, “assigning” durations for the tasks to be completed won’t really work unless you get some buy-in from the developers. Pick some durations, and then ask them “do you think this task can be completed in this time ?” If they don’t agree, you may need to negotiate. Or you may have to acknowledge that they don’t think it is realistic. But without some level of buy-in, 1) the developers won’t have much “incentive” to actually meet the schedule, and 2) you won’t have any recourse when they slip (“why didn’t you complete this task in this duration ?”).
As to statusing, daily seems to “micro”. If tasks typically take more than 1 day, then most of the status you take on a daily check will be “in progress” - not of much use, and daily status just becomes annoying. Depending on the length of the tasks, usually once a week should be sufficient. This isn’t always true, but is generally the case.
The key to statusing tasks that are slipping is not “how much is complete ?”, but rather “how much longer do you believe it will take ?” If you ask “how much is complete ?” you open yourself up to replies like “90%” or “95%” - close, but no indication of how much longer. If you ask “how much longer ?”, again, you are getting some commitment/buy-in from the developer on completing the task within a given timeframe. The difference is subtle, but important.
Developers are intelligent, creative people. But are also notorious for being terrible estimators - in both extremes, but typically in underestimating (tasks always seem easier than they turn out to be). It may take years to “calibrate” the various developers, if it is even possible. But you’ll soon get a feel for the people who are grossly off from their estimates. And you can account for that in your schedule.
Developers also need to stay on track - not get caught up in one aspect and lose sight of the whole task. Instead of the daily group meeting, I would recommend “making the rounds”. Stop by each developer (or just the ones who are prone to get sidetracked), and check in on them. Ask them what they’re working on, and make sure they are staying focused. Importantly, if you get a sense they are flailing and stuck on some issue, be thinking of ways to help them (have another developer work with them, etc.). Developers are also notorious for being convinced they can solve any problem - even if it takes them years Lastly, as you make the rounds, be sure to see if there is anything the develop needs (waiting on stuff from another developer, more information, etc.) that is holding them up. Developers may not let you know of any roadblocks that are holding them up.
Hope this helps. If you want to e-mail or PM me, feel free. (Yes, I was/am a developer. And then did project management)
The developers are asked to estimate hours for these high-level tasks when the proposal is made, and then they are typically inflated and signed off on by the lead developer and myself (the business development manager writes the proposal).
So we get projects in, these projects have hours for tasks (from the proposal).
Should i be creating a bank (backlog) of tasks related to projects with their hours, and creating project-based workflows for the guys? So the design guy would get a digital to-do list with all of the design tasks, and I would look for a status update/review every week with maybe a quick check in on his progress every so often?
I am thinking that would give them more independence in terms of knowing what to do (giving me more time to look at the numbers, write documentation that describes the scope of the project so the guys can do tasks, and solve conflicts related to projects)?
One thing that jumps out at me from the above is the “write documents that describes the scope of the project”. You sound like you’ve been dropped in the smelly stuff here by your management and by the previous PM leaving. I assume that the previous PM didn’t write up a Project Plan document? What have you received in terms of documentation from the previous PM?
Based on these I’m just wondering whether you have the option of going to your management (assuming you report into a manager who manages PM’s) and seeing if you can buy some time to get your head around things. Not having a clearly defined and agreed scope with the stakeholders before you head off on a project is asking to be dropped in it later on. Seeing if you can get some time to organise and get your documentation sorted out might help you out in the long term.
And without being too harsh to Leaffan, project management software does not equal project management
The previous PM relied on the proposal and discussions to get a project done. I know most companies rely on PRDs and I am starting to write these documents to describe functionality as the client wanted it.
I do not have a manager. Instead I have been working with the Business Development manager and I reached out to our other division, where there is a Sr. Project Manager. I am going to manage with the current chaos while she helps me once every other week make steps towards workflows that span an entire project (if it’s a month or two long).
I think that is a key component that is missing. The guys need to have a list of tasks to do, and I need to supply them with a Project Requirements Document to get it all done, and check on their status. Right?
To me that screams horrible, but project management works differently for different organisations. We always write up full project plan documents to describe how the project will run (scope definition, communication requirements, reporting requirements, issue and risk management, change management, roles and responsibilities etc), but I’m rarely on a project that lasts for less than 10 months to a year minimum.
Do you need to get down to the task level? Do these teams have a team leader who can parcel out the individual tasks to the team while you can parcel out the high level work to the team leader?
It depends on how well you know the teams involved and how your organisation works. For instance I can parcel out a high level work item like “launch these orders for North America” and the team leader parcels out the individual sections of that to their team to work on, they are then handed off downstream to enablement teams and throughout I gather up reports on progress. Admittedly I don’t have to account for individual work hours in my organisation but perhaps something similar could work for you? Assign the high level work to the team leader, they pass it off to the team to complete, you receive reports from the team leader on progress and costing (work hours) involved. Meaning you can track progress at a higher level than trying to get your head around each individual task.
It’s a little difficult to answer without knowing your organisations culture, functional management arrangements, how deep down the work/task level your PM’s normally manage, what it is your are managing (I’ve no experience with managing website projects) and so on.
Yeah, our projects range from 3-6 months. I have started to create a process and I think it’s right: RFP (request for proposal) becomes Proposal…Proposal becomes PRD (product requirements document)…lead developer created Technical Requirements that correlate with PRD…and development begins. We’re finding a little homework prevents a done of design issues. It might be a cool chance for me to create standards and eventually a workflow/development process for the team…just for my own sake
Yeah, our proposals usually have high level tasks like “create site search” and my PRD is going to describe what that item should be (for all of these). Then I am thinking we create a design, development, systems, and QA workflow that lists all of those tasks, includes the PRD, and the hours expected for finish (then you basically have given your team months worth of hours to work from…and you just make sure you check status. I think this is a good idea?
They do not really know. I have found that I am left to define the process. So I am thinking I am going to work with the lead developer. His task will be to get the team to complete the project to the quality/programmatic standards level that is expected, and I will manage the task vs. hours framework from a high level.
Lastly, as you make the rounds, be sure to see if there is anything the develop needs (waiting on stuff from another developer, more information, etc.) that is holding them up. Developers may not let you know of any roadblocks that are holding them up.