I come from a 10 year background in technical project management at a large corporation. There, we did things in a very structured way. We had formal documentation, from early requirements and feature descriptions, through detailed technical specs, to thick system test plans. and everything in between. We used various PM software to track tasks, timelines, resources, etc. We had loads of status meetings. Granted, it seemed like a bit of overkill at times. But good or bad, we always knew where we were on a project.
I recently took on a project management job at a small software development shop. They do things completely differently. There's essentially *no* documentation, other than the odd scribble on a napkin. There's no formal development process. There's no project plan, other than "keep working until it seems like everything's done". Requirements and feature requests continue to be adding well into beta testing and even beyond. There are multiple "masters" that must be answered to, including the owner of the company.
My main project has me managing a few developers who have way more to do by the release date than seems humanly possible. There's no sense in trying to manage this the way I typically would - getting time estimates for each task, determining dependencies, mapping tasks out on the calendar, then tracking progress. The developers are basically just working on as much as possible as quickly as possible. Any traditional PM I tried to do would be obsolete by the next day.
So...
Is there any way to bring order to this type of chaos? (or at least what seems like chaos to me - although no one here seems to be nearly as freaked out as I feel) There are only a few developers working on the project, so it's not like I've got to manage 10 or 20 peole. But the task list is large, and it took the developers a while to get up to speed. I do realize that the way I'd normally do things won't work. So I'm looking for suggestions from those of you who may have been in a similar situation.
Thanks!
Saving Changes...
Sort By:
Anonymous
Its sounds like to me that the project doesn't need better managing, but the stakeholders and owners do. I am not sure how strong you relationship is with these individuals or if they like being told, but on projects that I have been involved with that come to this I call them all to a meeting and remind them of the triangle. I ask the each to pick two of the three. Then explain the impact on that decision, and then relate it to what is occuring and highlight the element that I require more of. It gets interesting when each stakeholder writes down different elements as their two, thats when you get them debating their priorty. Hopefully this should allow you to addresses the "two many chiefs" problem you have. Sounds like you are in for fun either way. Saving Changes...
Anonymous
Yes, the stakeholders and owners are more of the "problem" than the developers, who I sense would welcome a more structured project management approach. But the high level guys feel a lot of competitive pressure; our product is not unique and has to compete with similar solutions from much larger companies. Providing a rich feature set, and bringing them to market quickly is the primary way for us to win with customers. So time is not something we have much of.
Speaking of time, when you mention the "triangle", I assume you mean the "Good, fast, cheap: pick two" thing. Of course, I'd expect the response to be, "We must have *all* three, plus some other things!" Yes, we know that's unreasonable but it's the mindset here.
So it seems that my best approach is to slowly, delicately, and maybe a bit stealthily introduce some standard PM techniques, methodologies, and processes. It feels like getting kid to take his medicine without realizing what he's doing.
Saving Changes...
Hannah WolfSenior Program Manager| UbisoftSan Francisco, Ca, United States
Something else you might consider is providing your management with an analysis of what the lack of PM discipline is costing them -- missed deadlines, staff turnover, etc. Granted, it's not easy to do in an environment where nothing is documented, but I bet your developers have plenty of anecdotal information for you. Saving Changes...
Sounds to me like an iterative methodology is being employed by the development team and you are familiar with the old waterfall approach. I suggest you get familiar with some of the "newer" development methodologies so that you can then get an understanding where Project Management is needed. What does become important for the Project Manager is Client expectation management(setting priorities), Risk management, Issue management and fixing the "no more changes for this release" date. Saving Changes...
Anonymous
I agree with the agile approach. I was in the same situation in a small company with extreme deadlines, high amount a change, and little requirements or documentation. It will introduce some control without all the costly overhead. Two books I recommend are:
Agile and Iterative Development A Manager's Guide Author: Graig Larmen and Effective Project Management Author Robert K. Wysocki
A site I recommend is www.agilemodeling.com
Embrace the chaos, it might be fun. Beleive it or not I am hunting for a job right now and experience with agile methods seems pretty marketable.
Saving Changes...
Andrew CotterellTransformation Manager| World Intellectual Property OrganisationGeneva, Switzerland
I've worked with a number of organizations with this sort of working culture (it's common in internet start-ups and software houses that employ "star" developers) and they all follow a similer pattern over time. Thay may claim to be using an "agile" or "iterative" approach but their lack of PM and general development discipline always catches up with them in the end. They may have got by up until now not knowing what the various projects' scope, status and priority are or what the cost is of what's being worked on, but at some point they'll pay highly for it, typically when the market shifts against them or when one of their major projects goes badly wrong.
So, there are good business reasons to get things under control and, of course, it's now what you'll be measured by.
Your approach needs to be gentle but firm. You shouldn't interrupt any of the work in progress but you should start to get a decent measure of what that work is.
I would start by doing all of the status reporting work for the team members (by way of short, focussed chats to establish task status, issues et.c.) until it's well documented and structured enough to make their responsibility to maintain. Meanwhile, I would work on the project sponsors and stakeholders to retrospectively scope and define the projects. As the quality and quantity of the information you gather increases it will be natural for team members and stakeholders to contribute to it independently. Combine this with a proper communications strategy (including project and steering committee meetings) and you will automatically become the focal point for the project and, therefore, able to manage it. Saving Changes...
An interesting dilemma - I know it well and have the wounds to prove it. The question is really about the nature of the project. You describe it as something that is not technically difficult, perhaps more time consuming than anything. There is the trap. If you are building a house then you can't let the bricklayers start until the slab has been poured. If you're building the world's biggest particle accelerator, there are mysteries that have to solved before you begin, or at least the questions all have to be identifed. They're very different, but it sounds like you're building a house. If you can't get control of the subcontractors, then run down the block and work with a different crew before this one bites you so hard your wounds show in the next interview. Saving Changes...
This sounds like the stuff of future war stories. Having been in similar situations I have difficulty in understanding how project management will be redundant the next day, as fundamentally it is about managing risks and expectations. In the culture you describe changes may be almost whimsical or reactive, rather than essential or really required. With developers powering away you do need to get to a point of capturing what is coming through to ensure the really important items are recognised and not lost due to the whimsy of something else. In particular when changes start undoing changes requested last week/ day
When in doubt, fall back to spreadsheets and set up regular briefings. 2 short (<30 minute) meetings twice a week to make sure all the changes have been picked up. One way of managing the stakeholders through this is to then get them to decide on priorities - make them be accountable rather than throwing things in and expecting everything to happen (and possibly scream when they don't). This is especially important where there are multiple masters as it is better for them to "debate" each other than you being in the middle. Saving Changes...
