Project Management For Beginners? 168
lawpoop writes "At my current workplace, I'm tasked with creating a rather complicated and metastasizing web-database application. I've mostly been the sole 'IT guy' at my workplaces in the past, so I've never had to, nor taken the time, to learn proper project management routines — code comments mostly got me through it. Now for this project, it's getting somewhat hairy and I'm sensing that I need to start doing things in a more organized manner. What resources would you direct me to? Books? (I wouldn't mind buying one good one.) Websites? What do proper 'specs' look like? Must I use UML (seems complicated and unintuitive) or a simpler ER diagram? For this job, I just need to provide better estimates for completing features, but what will I need if/when I would be working with a team?"
A book I thought was good (Score:5, Informative)
I recommend Making Things Happen: Mastering Project Management (Theory in Practice) [amazon.com] by Scott Berkun. Berkun has quite a bit of experience working on and managing teams. You can check out his blog [scottberkun.com] for more info. and to get a taste of what his writing is like.
There are a ton of books out there - his blog has a sample chapter to read so you can see if this will work for you. I thought it was easy to read and covered quite a bit without getting bogged down. The table of contents [oreilly.com] breaks things down to a pretty low level - so that is another good way to see if it hits on what you need or if it might cover a lot of stuff you don't care about. I know I wish some of the people I've worked for had read it and took it to heart - especially the stuff about how not to annoy people.
Re: (Score:3, Informative)
Re:A book I thought was good (Score:5, Informative)
Making Things Happen is the second edition of The Art of Project Management. They cleaned some things up and I think added in some practical exercises - and changed the title. (I'm not sure about the exact differences because I never read the first edition) I think Berkun explains why they changed the name in the forward but my copy is at home and I can't remember for sure. It is unfortunately confusing.
Re: (Score:2)
Re:A book I thought was good (Score:4, Insightful)
After a long spell away from project management, I bought a few books to catch up on what I'd missed. I did read the Art of Project Management, but I wasn't that mesmerized by it (though I did start following Scott Berkun's blog [scottberkun.com]). It felt too sterile and academic as a starting point. Maybe it's better if you're already in the thick of it, and maybe the new edition is cleaner.
What did mesmerize me was Agile Estimating and Planning [amazon.com], by Mike Cohn, who also has a good blog [mountaingoatsoftware.com]. It's quick reading, in an appropriately lightweight style, and it introduces all the concepts of agile planning (independent of Scrum, XP, etc) in a way that... that...
Well, remember that one professor you had, who taught you biology by deriving it from chemistry from physics from mathematics [xkcd.com]? Cohn explains agile planning from first principles, in a way that made me wonder how we spent two decades not realizing how obvious it was. My forehead hurt from all the slapping. Of course! Why are we forcing humans to estimate time and to calibrate their estimates? All we know is "hard" and "easy"; estimate in points, track your velocity, and let a smart computer figure out what that means in weeks. Of course! We don't need to plan hour-by-hour for dates 18 months away; we don't even know what we'll consider important than.
If you're considering agile methodologies, you must buy this book. If you're considering traditional top-down/waterfall planning, do yourself a favor - just slap your forehead every day. It'll build up calluses for when you buy the book later.
Re: (Score:2)
I think lawpoop is confused. He keeps calling it "project management", but if you RTFA (I know...) he's actually asking about software engineering.
I'm currently taking a software engineering class and our assigned text is Software Engineering: A Practitioner's Approach [amazon.com]. However, we've never opened it. My instructor says it's a "good reference", but he doesn't agree with everything in there. He teaches his own method, which he's developed while working as a software engineer for a large defense contractor fo
ITIL (Score:5, Insightful)
Start there. There's a ton of stuff online. If you can get your work to spring for certification, great. If it doesn't, no worries. Project Management is easy. Just keep in mind a few things:
- You need a project schedule with milestones. Live by it. Make others live by it.
- Understand GANTT charts. Don't necessarily use them, but the principles behind are solid.
- Google is your friend. The wikipedia article is actually a good start.
- Above all, understand that this is a team effort. You won't succeed without others. Time to start honing those social skills.
Re:ITIL (Score:4, Informative)
Re: (Score:3, Insightful)
Be careful with ITIL as it can massively overcomplicate things for people trying to do the bare minimum that works. We used ITIL based software at our company for release and service management and talk about overhead.
My recommendation is to do a lot of reading to familiarize yourself with the topics.
- Start with a basic analysis and design book (which will walk through requirements). From there you'll get ideas of other books you need to read.
- Many of your questions are ask
Re: (Score:3, Interesting)
Spot on. ITIL is not for the faint of heart, and should be applied appropriately. That said, it provides a ton of useful information about how things should be done. Compare that with what you need, use what makes sense, and move on.
And yes, it sounds more like he's moving on from being a code monkey to actually being responsible for the development lifecycle of a piece of software, so development lead stuff is a good place to start.
Re: (Score:2)
I want to highlight the team effort aspect.
The major failures that I see in projects by new project managers often turn on not asking for availability by secondary and tertiary teams such as testing, documentation, and installation teams.
---
I like RUP methodology a lot. It uses agile concepts and has a high focus on identifying "risks" early.
This is a wonderful concept that has helped me many times. Break the project into pieces that are easy to crank out and those which are unproven ("risks"). Resolve a
Re:ITIL (Score:5, Informative)
In addition, be be careful with your requirements, specifications, and testing.
Your users and customers (two related but often slightly different groups) are supposed to come up with the requirements, but often they are clueless on what they need. So you will often need to help them with suggested feasible solutions. However, the ultimate decision on what is REQUIRED is theirs. Just be sure to help them with the difference between required vs nice to have vs "you have got to be dreaming". The budget and time estimate is based on the requirement.
ONCE THE REQUIREMENTS ARE LOCKED DOWN you do not accept changes to them. Any changes go into a NEW requirement that will be harmonized with the old one at a later date. Think of it like a train leaving the station. No new passengers get on, none of the old ones jump off, except under controlled conditions. If the users want to change the requirement, tell them to get on the next train. As the PM, you decide when the new stuff can be included into the old AND HOW MUCH IT WILL COST TO DO IT. Never let them think it will be "free".
Getting a good estimate from the written requirement is tough. Trying to determine Function Points and lines of code and complexity and speed of development is a serious art form. Get good people and go over it a lot, from different angles. If you are lucky, this project is similar enough to past projects that you won't plant the seeds of destruction at this stage. You need to be sure you can really live with the cost and time estimate you give them. DO NOT ASSUME BEST CASE just because it look "easy". Too many people do. DON'T JUST DOUBLE EVERYTHING unknown. that is just wasteful. If you have serious unknowns, do some risk reduction explorations to be sure you do know what you are talking about (or at least plan to do them so you will know when the time comes).
The best specifications are testable. And the Tests should be written at about the time the specs are written. A Requirement might say "full color display". A Specification might say, "display in at least six colors, including white, black, red, green, blue, cyan, magenta, and yellow". Guess what the acceptance test is going to look for? It should be as Unambiguous as possible. This is where team work is good. Don't let the designer write the specs and the tests. Too much chance for hidden assumptions to creep in.
Which reminds me, be sure to explicitly lay out the overall software design, all the modules, all the interfaces, and subject them all to thorough rigorous Reviews. Too many otherwise good projects die from unstated assumptions that lurk under the surface. The coders are so anxious to get started they forget to examine where they are and where they are going vs the tools and skills available. They never see the iceberg until too late.
Please do your best not to become another "out of control software project".
Re: (Score:3, Insightful)
"ONCE THE REQUIREMENTS ARE LOCKED DOWN you do not accept changes to them. "
Unless, of course, you are using an iterative or agile methodology.
I am not sure the original poster is asking about project management... It sounded to me more like "development project management". Because full-blown project management involves everything for a project - initial stages, getting the line of business engaged, development, testing, user acceptance, implementation, support, overall budget, training, etc etc etc. It's
Re: (Score:2)
Agile is great for quickly verifying your project is moving in the right direction. I'm just wary of it being use as a substitute for a robust system design. Users might be happy with the basic functionality they see, but they may not be in a good position to see the big picture of long term maintenance or system architecture. If adding a new function turns into a massive hack to get it to work, you aren't doing them a favor by being highly responsive up front.
But by no means are the two mutually exclusi
Re: (Score:2)
Agile is great for quickly verifying your project is moving in the right direction. I'm just wary of it being use as a substitute for a robust system design. Users might be happy with the basic functionality they see, but they may not be in a good position to see the big picture of long term maintenance or system architecture. If adding a new function turns into a massive hack to get it to work, you aren't doing them a favor by being highly responsive up front.
Actually, you ARE doing them a big favor by fi
Re: (Score:2)
Unless, of course, you are using an iterative or agile methodology.
Especially if you're doing iterative development. What did you think the next train was?
Re:ITIL (Score:5, Insightful)
Of course, if they don't like what they see, you have a different problem. Figure out how to get on the right track.
Re: (Score:2)
It isn't about waterfall methodology vs anything else at all. It is more about Hitting the target, and trying to keep the target from moving more than absolutely necessary.
I would personally prefer that all requirements be firm and well known in advance. Then have a firm spec developed, then have a fixed and approved design, etc. It probably is not going to be possible or practical to do business that way, but it would be nice.
But what IS possible is to avoid having a new and unvetted requirement suddenly
Re: (Score:2, Insightful)
ONCE THE REQUIREMENTS ARE LOCKED DOWN you do not accept changes to them.
I would add.. do not let the customer increase the process overhead either
This is unusual, but I once had a customer who was actually more interested in the process than product! As I got stuck into the project, he'd frequently drop by and demand a "process" item, such as a plan, a demo, a design document, etc. Initially I responded positively, but that just increased his demands, until it was seriously interferring with the project, and, incredibly, he knew it! When I started resisting the demands (in orde
Re: (Score:2)
When I started resisting the demands (in order to get on with the job) he accused me of trying to "hide something" from him. [...] the lesson is - treat process as a contract, as much as the functional requirements. If they ask for more, just say "no"
Another lesson could be that when your client feels uncertainty and doubt, actively make this a topic and ask how that feeling can be alleviated. The problem should probably be fixed by the client himself, for instance by paying an external auditing party, by paying for extra deliveries and so on.
Re: (Score:2)
There is a lot more to managing a software development project than project management. Gantt charts are great for the time management aspect of a software development project but what the client is paying for isn't effective use of the team. It is a quality application delivered on time and on target. That means relevant and well articulated requirements, good analysis, accurate estimates, flexible and relevant architectures (both software and information), well written code, and consistent testing covera
Re: (Score:2)
Plans can change. Just don't change it without telling anyone. Telling them BEFORE the change, that is. If you do it after they'll figure it out on their own. During the investigation / witch hunt.
Re: (Score:2)
Eight is at least six...
Re: (Score:2)
This strategy may work if you are doing contract work, but if you are an employee it can be harder to make this stick.
Further, even if you are on contract, sometimes you have no choice but to accept changes... although if your original scope of work document was done properly, you are then able to charge more when changes are made.
Re: (Score:2)
If you really believe all of those tools will come up with the same answer, you are the fool. They are incredibly useful. But it still takes expert interpretation to turn them into useful information.
Try this on for size: I want a program that says "Hello World!". That is the entire requirement. Give me a time and cost estimate to get it done.
Hint: how many languages and operating environments are there? Don't forget output to video display, to printers, to plotters, or to audio output.
Even a really
Re: (Score:2, Funny)
and there's no u in "winning team"
PSP (Score:3, Insightful)
Something that may be of interest to you is the Personal Software Process, see http://www.sei.cmu.edu/publications/books/process/psp-self-improvement.html [cmu.edu]
That useless piece of s*** (Score:3, Insightful)
It is useful for getting in the way of getting work done. Or if what you're doing is something you've done before, in exactly the same way. In which case, why don't you just use what you've already done?
God help you if some PM makes you use it when you're wringing out a new API on a new platform.
PMI (Score:4, Informative)
Now go research about it, as a good PM needs to be able to do the legwork, too, not just shout orders around.
Re: (Score:3, Informative)
www.pmi.org
Re: (Score:2)
So do you have any suggestions about what books or sources to look at for information about PMI methodology?
The canonical bok is the PMBOK [wikipedia.org] - A Guide to the Project Management Body of Knowledge. That said, this is more of a reference/guide than an introductory book. I strongly recommend at least getting a companion book - like Head First PMP [headfirstlabs.com]. In addition, you should look at getting some training - you can't get a certification for a couple of years, but the training is very useful.
Only as much as you need (Score:5, Interesting)
Re:Only as much as you need (Score:5, Insightful)
Re: (Score:2)
From a experienced project management viewpoint, anyone who is asking these questions prior to starting a complex project where it has been stipulated that they have to provide 'better' estimates for completing features, is in real trouble. Attempting to learn project management whilst winging it in on a hope and a prayer on a current project is not the most sensible thing to do.
My advice would be to admit the limits of of experience to management, hire in a reputable consultant and pay attention to what
Re:Only as much as you need (Score:5, Informative)
Mod parent up. With all due respect to other posters, sending the submitter to ITIL is overkill. Talk about drinking from the firehose.
I use to run a number of development teams in a systems integration and custom development shop: We took our employer's base products and toolkits and integrated them into customer environments. We did a lot of "1.0's" - typical projects were 2 to 6 weeks in length and if we ever saw them again, we lost money. We could afford one or two moderate bugs (sev 3 - functionality impaired); more than that, we lost money. We could not afford major bugs (sev 1 - all is borked; sev 2 - most is borked). And given the tight timelines, we had to be very sure that what we were developing was what the customer asked for and what the customer asked for was what the customer wanted.
We almost always made money and our customers were almost always very satisfied. We very rarely lost money, and it was usually on strategic projects (spend integration money to make more license money).
Here's what we did:
Handling exceptions. If at any point things start to drift out of alignment, stop. Figure it out. If the problem was the high-level design, go back to the customer. Otherwise, it's an internal issue you have to identify and correct.
VIP: Acceptance test plan. Having the acceptance test plan signed off by the customer is crucial. If they sign it off and everyone codes to it and it aligns with the high-level design and the deliverable passes acceptance, then you are done.
One thing I've left out: Change requests. They are the bane of every project under development. You need to dig in your heels and manage them properly. Work collaboratively with the
Re: (Score:2)
This is one of the first posts I've ever wanted to mod to +6.
In my experience, the parent is spot on, even for "internal" projects where IT is building business applications for another department.
Re: (Score:2)
Re: (Score:2)
This is one of the first posts I've ever wanted to mod to +6.
Quick, let's grab the slashcode and make it go to 11!
Of course, that will mean converting it to use base 5, but that might be cool. Today would be the 43rd day of the 4th month of the 31014th year, for example.
Seriously, thanks - I've got a little glow of slashpride right now!
Re: (Score:2)
Customer reviews design, expected ship date, signs off. (Because the design has to be fit for the customer, no UML diagrams or fancy methodologies that the customer doesn't understand. These things have their place, to be sure. But if you cannot describe it in pictures and words, it may be too complicated for you and your organization's current level of development methodology.)
Pretty good post, but my quibbles would be:
o Use Case diagrams are UML. The convey, quickly and clearly, who can do things with the system and what they can do. And it's really important that if you are unable to do something, you have a Use Case that shows a person doing something with a 'You Can't Do This!' on it (or, preferably, "you will be able to do this in version 2.0"). It's largely about 'managing expections' by the customer.
o Design must mean something different to you than it does to
Re: (Score:2)
Use Case diagrams are UML
Excellent point - as are all of your "quibbles" (which I think you use to mean "pithy and accurate observation" - at least that's the sense I get from your post :->).
I poorly expressed the point I was trying to make when I wrote "no UML". I meant something more along the lines of "no jargon", no specialized terminology or diagrams that are unfamiliar to a non-technical audience. For example, "actors" and "agents" have specific meanings in various contexts, and while developers
Re: (Score:3, Insightful)
Re: (Score:2)
I agree with the parent. In your case, while you are taking on a bigger project, you are not being called upon to manage multiple resources, multiple dependencies etc. That's a large part of what project management is. It sounds like you're more after something that can act as a guide to software development. A nice, short, practical book is "UML Distilled" by Martin Fowler. While it is geared towards teaching the application of UML, it does so by describing it's various diagrams in context and showing
Re: (Score:3, Insightful)
Re: (Score:2, Interesting)
This is a great post. Just to add my bit on top of this. I forget who said it but one quote I quite like is:
"The most important thing is to keep the most important thing the most important thing."
At the end of the day your task is to get a job done and a large part of that is going to be managing information flow and keeping it flowing as freely as possible between yourself and everyone else involved (management, end users, you, other developers etc). Simple things such as a big whiteboard, a properl
Back to basics (Score:2)
1 - Start with PM basis: the book "Head First PMP" seems like a good start (and yes I read it)
2 - Go learn about Scrum/XP/etc that's what (I and a lot of people) to be the realistic approach for sw pm today, stay away from RUP/Waterfall, etc
Otherwise, a book I found nice is "Software project Survival Guide" http://www.amazon.com/Software-Project-Survival-Guide-Practices/dp/1572316217 [amazon.com] even though it's a bit on the side of waterfall.
You could go directly to Scrum/XP but it's nice to learn about 'classic PM' f
Re: (Score:2)
That's like saying "Go learn Java (or C# or Ruby or...) only because that's what I and a lot of people say is the realistic approach." THEY'RE ALL TOOLS FOR THE ARSENAL, AND YOU SHOULD BE FAMILIAR WITH ALL OF THEM.
Just as what language you use is a choice depending on the skills of the team, the hardware at the company, and the project at hand; the project manageme
Re: (Score:2)
As others have already commented, Agile is one option but unless you want to be the guy in the corner pounding on screws with a hammer, I'd suggest reading a little about several methodologies and then dig deeper into one methodology when you have a situation that fits.
Remember, the OP is in a single person environment, that alone is going to make daily team meetings a little challenging (or at least a little odd to watch).
Other options include Critical Path, which can be executed with a waterfall model but
PMI and ITIL (Score:3, Insightful)
I'd recommend starting out with the PMI body of knowledge...start here: PMI [pmi.org]. ITIL is a very good framework for designing an ideal operational environment, but it's huge and very bureaucracy-centric if you're not careful. The ITIL content is not free, but you can take training courses or buy it yourself.
All that said, don't underestimate what you're getting into. Project management is not IT work. The job you do as a PM is totally different from anything you're going to do in your IT job. For one, you can't do any of the work yourself. A PM's job (in my estimation) seems to be begging and pleading workers and their managers to get things done on time.
Also, project management, like people management is a skill. You can either do it or you can't. I've seen IT guys promoted to project managers who fail horribly at it. Remember that you're not the "doer" anymore, all you do is keep records, hold meetings and yell at people who miss their dates. On the flip side, a truly good PM with IT skills is a godsend. Being able to understand that an IT project is NOT a construction project is a key skill. Traditional PMs will tell you that a project is a project. However, you know EXACTLY how long it takes a carpentry crew to frame a house, a plumber to lay pipe, and a drywall crew to put up walls. You sometimes have no idea how long it will take to find $obscure_bug[n]. Construction projects have at least a chance of coming in on time, and IT projects really don't unless they're totally simplistic. Keep that in mind and you'll do well!
Comment removed (Score:4, Insightful)
Re: (Score:2)
#4 leads to a pretty key point. An issue that I've seen on some bigger projects is when the project manager has a hard time accepting the fact that their job isn't as much to "do the work" as it is to manage the people who are doing the work. There's something to be said for leading by example, staying involved, and not losing touch with the grunt work, but it's important to realize that on a project that's continually progressing, project management is a full-time job.
If the project manager is putting 20 h
Site with templates (Score:2)
Talk to someone in person (Score:3, Insightful)
This is a big topic, and there are lots of different "right" answers. The best one for you depends a lot on you, your project, your workplace, and your future team.
Try to find someone that you can talk to face-to-face for 30 minutes over a coffee or beer. You'll learn a lot more from their experience in that time than any amount of reading and you'll then have a better idea of which way to direct your energies and further research.
Ideally someone with a similar project to yours, but really, anyone with a bit of experience (the more the better, as they would have seen more methodologies) can help.
Bare Bones Project Managment (Score:2, Interesting)
It's pretty cheap ($8.95 + S&H) and bypasses a lot of the fluff that's not needed for anything except huge projects.
Use crowdsourcing! (Score:2)
All my management skills I learned (Score:3, Funny)
in Army Basic Training.
Which is why I'm not in management...
Re: (Score:3, Funny)
Because you cant lob a grenade in the direction of the problem to make it go away.
Corporate America frowns on that.
Re: (Score:3, Funny)
Because you cant lob a grenade in the direction of the problem to make it go away.
Corporate America frowns on that.
Pussies.
Use trac for guiding you (Score:2)
The project roadmap feature of trac is nice to help you set up your project.
First define the partitioning of your project as trac components, so that it is easier to assign tasks, features, bug tracking, etc. Then define your roadmap. Enter features on components as different tickets and assign them accordingly to your roadmap. Maybe you know other systems, but having a good central database for assigning and completing tasks and being able to track progress with it is invaluable. trac is really good and w
Rules of Thumb (Score:4, Interesting)
Re: (Score:2)
Essentially you are correct. But in this case the question was from someone new to project management. From the conext of the question i took, that those managed by him are as new to being project managed by him as he is project managing them. In that case we probably two effects:
The Cathedral and the Bazaar (Score:2)
This may be an odd choice for some but I found it a great read for team leaders and project coordinators.
Eric tends to compare himself and his achievements of fetchmail to that of Linus Torvalds and Linux which I personally found distracting but...off topic.
Re: (Score:2)
Basecamp... (Score:2, Interesting)
Triple constraint (Score:4, Insightful)
Understand the triple constraint, and more importantly, make sure those above you understand it as well. Much like the old adage 'you can have it cheap, fast, or good. pick any two.' Cost, time, and scope. A change to any one affects the others.
- Due date got moved up? Project just got more expensive or lost a feature or two.
- Scope increased? It's going to take longer or cost more.
- funding decreased? Lose features or increase project duration.
Leave it to the sponsor to determine how to deal, but be certain that they understand how things affect one another.
Practical Project Management by Michael Dobson is a good intro*. It's clear and uses good examples, without digging too much into the PMBOKish stuff that can be overwhelming when starting out.
*disclaimer -- I didn't read it all (dove into the PMBOK to prep for the test), but very much liked what I read. Plan to go back to it someday.
Process and execution (Score:2, Insightful)
Metastasizing?! (Score:4, Funny)
At my current workplace, I'm tasked with creating a rather complicated and metastasizing web-database application.
I don't think that word means what you think it means, unless the "web-database application" moves to new hosts on it's own..
Metastasis
a. the transference of disease-producing organisms or of malignant or cancerous cells to other parts of the body by way of the blood or lymphatic vessels or membranous surface.
b. the condition produced by this.
Wait, you're trying to tell us you work for skynet, aren't you? Carry on, then.
Re: (Score:2)
I thought metastasizing was a perfect word to describe a project where scope creep has been replaced by scope gallop. One where new requirements seem to come from everywhere, sprouting from what was once a tightly defined product.
Re: (Score:2)
``I thought metastasizing was a perfect word to describe a project where scope creep has been replaced by scope gallop. One where new requirements seem to come from everywhere, sprouting from what was once a tightly defined product.''
My experience is that web applications tend to be like this. The barrier to entry is low and there is often a lot of competition. Once a competitor implements a good idea, there is a lot of pressure to duplicate that idea in your own product. If you opt to go this way, many tra
Check out FogBugz! (Score:2, Interesting)
Check out FogBugz - they even give away a free "startup edition" for 1 or 2 people to use. It's either something you install on your own server, or use the on-demand "hosted" version. I use the latter, and it's great.
http://www.fogbugz.com
PMBOK (Score:2, Informative)
Bare Bones Project Management (Score:2, Informative)
UML Reference Martin Fowler (Score:3, Interesting)
Another way to look at it... (Score:5, Insightful)
A lot of good suggestions above. I'll add the following: Project management is the art of creating lists of tasks and getting them done. It's really as simple as that, and it's also more complex.
You need a list of your requirements. What are the things your system needs to do?
You need a list of things you'll develop to meet the requirements. These include the pages, the back end modules, the database schema/tables, etc.
You need a list of the tests you're going to perform.
You need a list of the steps to move into production.
The act of creating these lists will force you through the process of thinking through your project. Assigning elements from these lists to other people is how you get the project done. Understanding the dependencies between the items on the list identifies your path through the project. Watching how items get added to these lists lets you know whether your project is under control (high addition/change rate is bad).
The process of formal project management just codifies certain documentation approaches to the above. You can do everything you need in Excel/word, or use tools like MS-Project. The fancy tools are overkill for a small team/project.
Many of the disciples of project management lose sight of the fact that a project plan is not the end goal, it's a visualization of the work to be done. When you have enough detail in the plan so you can understand the work to be done well enough to estimate it, assign it, understand the dependencies you need to manage, and report your status to yourself and interested parties, you're done.
That's my take. I have 20+ years of project management experience, sometimes while being called a project manager.
Re: (Score:2)
I have 20+ years of project management experience, sometimes while being called a project manager.
Just curious... What were you being called other times?
Names? Liar? Scapegoat? Catbert, Destoyer-of-Marriages? Head slave-driver?
Re: (Score:2)
Bastard, Shithead, God of Delivery... Slave Driver was in there, as well. A couple of the folks called me "The Best Manager I ever had". They were the same folks who called me "Slave Driver".
Seriously, I have been variously labeled Manager of IT, Engagement Manager, Product Manager, Program Manager, Business Systems Architect, and Lead Developer.
Re: (Score:2)
I think you're confusing goals with the process. Yes, the goal is timely completion within the budget while meeting quality requirements. But how do you approach that?
I'll stand by my assertion. I've managed projects with budgets of 10,000 man days and more, and brought them in on schedule, as contracted for, and under budget (sometimes). I've managed agile projects with 5 developers. I've managed system integrations, data center moves, packaged software installations, and office moves. It's all lists,
Process and Book Suggestions (Score:3, Interesting)
First I want to say that several of the comments that came before are very good. There is a wide variety of experience and can help you get started.
I would say start as small as you can and expect to not get it right. Take your big project and break in into a few smaller easier to digest sections. You are going to make mistakes, but as you practice and you get you company more used the process will evolve and work better.
I won't give you specific examples of process, because I am not familiar with your organization and the process will have to be tailored for you company to work well. I will give you two books I feel are good to help. I read a lot of books on project management and I think these two are very good starter book.
Information Technology Project Management , Kathy Schwalbe
and
Managing Software Development Projects: Formula for Success , Neal Whitten
The Fast Forward MBA in Project Management (Score:3, Informative)
We used this book for my project management class in grad school. It's very easy to use and seek out specific information. The methodologies it explains are straightforward and easy to implement as well.
Some recommended reading (Score:3, Insightful)
I've been a project manager for a couple of years now. Still have lots to learn. The basics:
- Scope: Define the project and what it's going to deliver.
- Requirements: Define the finish line, what's the product or service your project is going to deliver.
- ONE BUSINESS OWNER/SPONSER: Who has the purse-strings and will sign off on the completion of the project.
- Activities and Milestones: Define what needs to be done and pick off some deliverables on the way to completion, so you can show everyone (and yourself) you're making progress.
- Schedule: Put the activities and milestones on the calendar. Do you have people who can complete those activities and deliver the milestones? (Have you factored in vacation time...?)
Some recommended reading:
Head First PMP--the PMBOK is dry, Head First made it very accessible.
The Art of Project Management, by Scott Berkun--Learned a lot from this book. I come back to it time and again for ideas.
Managing Humans, by Michael Lopp--Enjoyable read, got some good ideas. A lot of the chapters in the book can be found at www.randsinrepose.com
Another recommendation: Get a mentor. Check out the local PMI chapter (www.pmi.org) and see if they have a mentoring program.
Good luck!
Do something radical... (Score:4, Interesting)
Hire an experienced person on contract to get you started and mentor/teach your team how to do a professional job of software development.
Stonewolf
Do It Like My Project Manager (Score:2)
Refer to yourself as "The Architect," then hire a couple of people to clean-up after you're done "architecting."
ONE book? (Score:2)
Is it an actual project (Score:2)
with many people, or is it just you?
If it is people, pmbok. Most college offer some sort of basic class geared towards pmbok. Take some.
If it is just you, then create and archetecture, modularize it, then break all the moduals down into code(pseudo) chucnks, then break the chunks into bit.
Then start programming.
Naturally every step requires communication with stake holders. Identify them immediatly.
Look up what a stake holder is, most people don't actual know how to identify stake holders.
Re: (Score:2)
Naturally every step requires communication with stake holders. Identify them immediatly.
Look up what a stake holder is, most people don't actual know how to identify stake holders.
</quote>
I'll give you a hint. Users are not usually stakeholders. And stakeholders are not usually users. Oh how obtuse was that? Lol.
Want to say thanks to everyone's input (Score:4, Interesting)
I'm glad this question was posted because I have come to the conclusion that no matter how good I am at my current job, I'm bored and need to continue to advance myself. Unfortunately, because I work in a government environment, upgrading your skills is somewhat difficult due to union regulations about who does what as well as the whole "who you know" nonsense.
As a result, I've taken stock of what skills I do have and have realized the "Those who can't, teach" rule applies to me and will (hopefully) be shifting gears in the (very) near future. Specifically, project management.
If all goes well, I'll be heading back to school in the fall (while still working) to get a degree in IT Project Management using both credits I've earned in other computer classes as well as life experiences. I'm still waiting on word from the school as to how many credits I can transfer so we have an idea of what classes I need to take.
The information provided here, some of which I already knew about, is invaluable and while I'm one of those who will bitch about the cruft you folks sometimes write when responding, the responses so far are probably the most informative I've seen in a long time.
Thanks again and keep those suggestions coming.
P.S. If anyone has an opening for a low level PM, drop me a note. Organization and the ability to see the entire project, and in what order things need to be done, are my forté.
Lean Development (Score:2)
I personally really related to these, as I'm a software guy with a Mechanical Engineering degree...
An Agile sphincter (Score:2)
I like this bit: "If you plan on using Agile to get out of writing proper documentation, then get ready to agile your sphincter for the angry client."
Anything by... (Score:2)
Get yourself a good management tool (Score:2)
I suggest to look into Scrum (Score:2)
First thing is: forget about milestones. Milestones have 2 problems: first they put a fixed date for delivery, that means a fixed amount of time. Second they assume a fixed amount of work done until that Milestone. And finally they assume the work aka code is "finished", "polished" and tested.
Currently you say that you want to do better estimates ... with no experience and likely no reference data this is nearly impossible to do with milestones.
The most important thing is to get an idea about your "speed" o
Recommended books (Score:2)
Focus (Score:2)
You've lost focus already before you started. Project management is not about reading books, using uml or not or whatever. Project management is about knowing what needs to be done and ensuring it gets done in time. So, instead of reading a book, what you should do is:
1. Ensure you know what needs to be done (this involves things like requirements, customers, deadlines, versions, quality assurance etc.)
2. Make a plan on how to get that done (this involves things like requirements engineers, software enginee
Re: (Score:2, Informative)
Do you have a web link to specific tools?
'Agile Software Development' is a 21st century buzzword, just like XML, LAMP, OO, and eXtreme Programming were some buzzwords of the 20th century.
A multitude of vendors claim their tools are for or support 'agile' development, whether they're really useful or not, is another matter....
Re: (Score:2, Informative)
'Agile' is a class of software methodologies. A popular Agile methodology is called Scrum. An excellent resource on how to conduct a Scrum shop is 'Agile Project Management with Scrum,' by Ken Schwaber. A good place to get started is http://www.mountaingoatsoftware.com/scrum/ [mountaingoatsoftware.com].
Re: (Score:2, Informative)
There's also 'Agile Software Development with Scrum,' same author. There are people who consider it to be the Scrum bible.
Test driven development (Score:3, Insightful)
When it comes to writing a good design document, use whatever you feel most comfortable. Yes - UML is a highly expressive way of describing the life cycle of a system but if it isn't familiar to you, you'll be better off with a list of things that it is supposed to do. Ideally, the design document should be readable by every one who has some requirement from the design. This does sometimes mean that you need to split your design into externals (what the customer sees) and internals.
One technique that I ha
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
Parent AC is from Scott Berkun (Score:2)
Re: (Score:2)