Slashdot Mirror
Project Management For Beginners?
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?"
I recommend Making Things Happen: Mastering Project Management (Theory in Practice) by Scott Berkun. Berkun has quite a bit of experience working on and managing teams. You can check out his blog 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 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.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
I would suggest to look at Agile Software Development and planning tools. These are lightweight and highly effective, especially in constant changing environments (read requirements).
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.
Those who can, do. Those who can't, sue.
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
"If anyone needs me, I'm in the angry dome."
I suggest using the PMI methodology, as it is the industry standard, it'll add a lot of credibility to your resume, and make life much easier for those who follow your work (co-workers, or the guy replacing you once you brush up that resume with a PMI cert).
Now go research about it, as a good PM needs to be able to do the legwork, too, not just shout orders around.
Might be slight overkill if you're just working on this alone, but if you need to communicate/collaborate with others, you might take a gander at the product I work on:
http://kalexo.com/our-products
My general approach so far has been:
- Write a design document pretending that someone else of your skill level is supposed to implement the solution based on that document. It helps reveal holes in your design, or at least strengthens your confidence.
- Figure out the toughest/trickiest parts and prototype them first. That way you reduce the amount of last-minute surprises and can make a better estimate.
- UML or pseudo-UML can definitely help. Get a whiteboard and keep it updated. It helps you keep the big picture when you're deep in low-level code.
Ubuntu on primary work desktop since Dapper Drake (2006).
My advice is to adopt only the project management tools and methods that you need to get the job done effectively. It is all too easy to become mired in learning a complex discipline (project management) when all you really need is a well thought out flow chart and a good ER diagram. In other words, do not spend your valuable time trying to learn MS Project or any of the several readily available alternatives. They are tools for someone well-schooled in the techniques in managing complex projects. Your flow chart could easily expand into groups of related tasks, one grouping for each element in the chart. To manage that, a simple task list manager will do.
May I suggest your public library? More libraries have taken to stocking books for professional development as a way to increase readership.
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 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' first, it helps with vocabulary and the general idea.
how long until
Software development is turning into a branch of sociology rather than an application of computer science. All these bloody "methodologies". No wonder software gets ever more complex and slow, and there's little in the way of innovation - it's all just implementing old theory.
And now for the selfless answer you won't like: the economy is fairly shit today. There are many highly skilled individuals who would have more experience doing what you're trying to do, but who are out of a job. The best way forward for the company is to offer them your job in return for a proportion of their first year's salary. You work together for a month or two, teaching him about the firm.
I'm not looking, but I'm sure other /. readers are.
I'd recommend starting out with the PMI body of knowledge...start here: PMI. 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!
http://en.wikipedia.org/wiki/Critical_chain
I've seen good results when applied (and bad results when applied poorly, but that goes for any methodology).
You didn't state whether or not you were on a team or not, but if you aren't, then just document the hell out of everything.
If you are become a project manager over a team, here are some helpful hints that someone should have told a boss I know at a different site from mine:
1) Learn the difference between delegation and dereliction.
2) Defend your team against outsiders unless your team is behaving indefensibly.
3) Your biggest job is to remove hurdles from your team's path. These may be helping them on technical decisions, but more commonly will be you marching into someone's office demanding their cooperation with your team when your subordinates cannot get any information or cooperation from them.
4) Don't take on more work than your team can handle unless you are willing to double up on helping them AND your management role.
Here is one site I found yesterday with templates, white papers, articles, etc. http://www.brighthub.com/office/project-management.aspx
Do really dense people warp space more than others?
I thought this was my weekly team meeting.
You're going to get a lot of answers here pointing to specific methodologies like Agile, but for someone just starting out I think it helps to understand what project management is and isn't.
The Project Management Institute (the ones that run the PMP certification program - pmi.org) is sort of the world repository of project management theory. They publish "A Guide to the Project Management Body of Knowledge" or PMBOK. Most practicing PMPs take everything in the PMBOK with a grain of salt, because it is an ideal vs. what happens in reality, but I think their definition of Project Management is a good one:
"Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements."
There are some good nuggets in there that I think can help a new project manager.
First is to understand that the whole point of a project is to meet some set of requirements. So you probably better know what those are before you start, and more importantly, you should know how to measure whether you've met them or not.
Next is to realize that you are managing project activities, or tasks. You need to have some idea of what things need to be done in order to meet a requirement, what resources (people/skills, money, time, etc.) are needed, and some idea of how long it's going to take.
Lastly, project management involves applying tools (like scheduling software, or gap analysis templates), techniques (like change control) and skills (like leadership) to tie it all together.
It doesn't particularly matter what your process is (agile, six sigma, etc.), but it is very important that you have one. Every professional PM I know adapts their corporate methodology to fit their style and the nature of the particular project. That's part of the "skills" in the PMI definition.
Project Management can really make your life easier and doesn't have to be an overly onerous process.
Good luck!
Project management is a way for middle management who know nothing about programming to make themselves feel useful and screw up your programming project....
Don't fall into that trap.. I did. Here is what I learned: 1) There is no complete answer to how to document a project. anyone that tells you otherwise probably doesn't code or support someone else's work. 2) Learning project management takes time and experience. A book won't help.. I have several and all are equally useless. 3) Project management doesn't sound like what you are looking for (like the other person above said, PM is for Middle Management). what you need to do is look at it from the outside. if you had to come in to support someone else's website/database, what would you need to be able to support it successfully? inputs, outputs, timings, schedule jobs, maintenance jobs, etc. Document what those are and how they run. Then create some basic flows to describe how the system integrates together. Being the only IT developer will make the documentation more difficult and you aren't going to get it right the first time (or first dozen times). Just be ready to add or remove information from your documentation as you go. Also, every time you have to research something, create a document that defines what the problem was and how you fixed it.. you or someone that follows you may need it to resolve future problems. And don't trust what I tell you to be true or final. You will find a better way as you go through it.
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.
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.
Best Slashdot Co
It sounds like you're primarily looking for advice on managing your application design and development, which isn't quite the same as traditional "project managament" - you're looking for help with part of the application lifecycle. But, just in case I'm mistaken and you are looking for help with project management, I recommend Bob Lewis's "Bare Bones Project Management" (Details here).
It's pretty cheap ($8.95 + S&H) and bypasses a lot of the fluff that's not needed for anything except huge projects.
Putting the "anal" back into "analyst"...
Post all the details of your project requirements, benchmarks, test cases, unit test modules and everything in Slashdot and ask for advice. You see, most slashdotters are jobless fellows who salivate at the idea of working their tails off to solve other peoples' problems. When you reap all the benefit of the contributions and laugh all the way to the bank, make sure your minions do not waste their time reading slashdot. Great Idea, Fellah.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
in Army Basic Training.
Which is why I'm not in management...
Best Slashdot Co
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 with relatively low overhead compared with other systems to start with.
Project Management is a profession in itself. Contrary to what many have stated here, it is not easy and that is because it encompasses far more than just schedules and budget. If you have a local chapter of PMI near you I recommend you join and pursue a PMP credential. Not only has it made my life easier, it has increased the success rate of my projects by a factor of three.
The Cathedral and the Bazaar by Eric S. Raymond
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.
~ Ron Fitzgerald
Basecamp has been the only thing ever that made me not hate doing PM. http://basecamphq.com/
-Matthew Riley "TofuMatt" MacPherson
I have a website
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.
Sweet informative mod.
You could go anywhere on this topic. I had a similar experience a couple years ago when I took up some leadership roles. I suppose one big thing for me was to recognize a distinction between process & technique. As you probably know, practically every software project is guided by fundamental process milestones: requirements, design, development, testing, documentation, release. You shouldn't deviate from this, but its up to you how you execute/implement this process ("technique"). That said, random thoughts:
...etc...etc...
1. Are you guys using SVN, CVS, VSS, PVCS, etc?
2. Get the requirements on paper. It'll save your *ss if something wasn't built to expectation. (This is more important if you work directly with clients.)
3. I agree with above posts: Your goal is to let the developers do their thing. And, perhaps even at this early stage, you probably need them more than they need you.
4. One hard thing is to say no to your peers/superiors if they infringe your team's priorities or "rights".
5. Most people don't like regular meetings, but I like status meetings (called with proper frequency) to keep everyone in tune and on schedule. Remember to show them the timelines, and repeat the priorities so that they understand the big picture.
6. Agile, Waterfall, RUP are formal processes. Google/Wiki it. Scrums are regular stand-up meetings.
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.
I put on my robe and wizard hat..
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 have found to be particularly effective is "test-driven development". That's another buzz-wordy phrase for your resume. However, this one carries significant benefits.
If at the time you write your design you also write a ready-to-run test suite to test your design, you will write a better, more complete design because you will have been forced to think about the scenarios your design must cope with. Further more, you also have a great way to assess your progress as the design is implemented. If you were thorough in writing your test suite, then you can gauge the functional completeness of your project by simply seeing how many of your tests are running successfully.
Oddly enough, this approach leads to faster development cycles because you always have a clear picture of what is working, what needs to be implemented still and what is not behaving as expected. It is also pretty motivating to write a couple of hundred lines of code and to be able to quickly run some tests to validate its function and see another two tests click through successfully.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
The most important part of project management is whipping programmers so they can make an artificial date. Its important to do this so the code quality can turn to crap and then the project can be cancelled or a new project can be created to redo the first one. What would we do without project management?
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
Yours, Francis Rath
The Zachman Framework is a great tool for organizing all the information you collect about a project and provides ways to interrelate that information. It's free-form enough to be scalable to all problems (document what you need to, store extra emphasis on things that are important) and it tries hard to not inflict more harm than good (not so rigid that every project can't be implemented in an entirely different if the problem demands so).
Having had to go this exact route, I started to take business analysis courses through a local college to compliment the IT knowledge and work through two fields. An excellent resource books is PMBOK http://www.amazon.ca/Guide-Project-Management-Body-Knowledge/dp/193069945X/ref=sr_1_1/190-4122478-2675606?ie=UTF8&s=books&qid=1240410769&sr=1-1. The book is really straight forward in general concepts and will give you a good fundamental understanding of project management. If you wish to follow through, there is a designation certification as well. A lot of project management just comes down to being really good at making flow charts and having a general concept of lengths of 'reasonable' work to complete projects. You have to be really detailed oriented and have good common sense.
Bob Lewis's Bare Bones Project Management: What You Can't Not Do would be a good place to start. He writes an IT and project management related column for Infoworld.
Martin Fowler's UML Distilled is a great read. Roughly 200 pages it offers a concise introduction to UML which is a handy way to visualize software design and share ideas in a common and easy to use visual language.
1. write a COMPLETE spec with deliverables, don't deviate from it.
2. have your team review, note milestones and blocking issues
3. add up all the required time inputs from each team member.
4. Multiple time required by 2 (and budget) and ultimately you will be +-20% of the 2x estimated time and budget.
good luck young warrior.
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.
I was taught to respect my elders. The trouble is, it's getting harder and harder to find some.
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
http://classics.mit.edu/Tzu/artwar.html
http://www.amazon.com/Fast-Forward-Project-Management-Portable/dp/0470247894
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.
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!
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
Refer to yourself as "The Architect," then hire a couple of people to clean-up after you're done "architecting."
What?
I understand that you don't want to read 5000 pages right now to get up to speed, but I suggest that you're aiming low if you think you're going to get all of your management knowledge from one book. Consider one book now to get you on track for your current effort, but to really get good at it you will probably need to absorb (and process) information from several sources to come up with all of the detail you need in your unique environment.
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.
The Kruger Dunning explains most post on
If you are asking at the stage where things "are starting to get hairy" then it is too late. All is lost. It is time to open the third envelope. Your only hope is to hire a mean program manager to save you. Just stay behind them and do what ever they say!
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é.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
Managing Software Development Projects by Neal Whitten is approachable and has been very helpful to me.
As far as I can tell from how the last project I was on at my current employer, there are 2 things to keep in mind:
1. If you need someone on another team to support your project and they tell you that they already have stuff to do and you need to get in line behind other folks with important needs who had the foresight to plan and schedule the work, call up everyone you know at the next level up and argue until you get what you want NOW.
2. Never EVER allow timesheets to be late. If a team member is late in submitting a timesheet, call them in for a 1:1 to tell them how serious this issue is and could result in disciplinary action.
Those two should get you to the point where the software is in production. You can then take vacation while the rest of the team (that just finished working 24/7 for nearly a week) spends the next couple of weeks patching up all the holes in the system.
ACM offers many online courses in project management. Most of these are free to members.
Also take a look at http://www.jrothman.com/
I personally really related to these, as I'm a software guy with a Mechanical Engineering degree...
If you hire a good team, everything will take care of itself. The most important qualification is a history of successful, completed, on time, on budget projects.
Cheers
For your first project don't use any kind of software do it all manually.
I find this is the biggest problem. I manage MS Project Server for my company and can't stand it how people expect the software to do the planning and management.
MS Project is a great toolset but it is only that.. a tool.. A hammer doesn't build a house its all the planning and knowledge of building a house that gets the job done.
PMI is a great resource but don't take everything they do as it is written in stone. It is designed for huge projects and even at that they don't expect you to use all the methods on every project. I love PMI and PMP books but it is a quick way for a beginner to get confused.
Here's my 3 steps for getting started before buying a book or doing anything else:
1) I'd recommend talking to your team, individually, about what things on the project are most frustrating or could be improved.
2) In each conversation ask for their advice on what you can do, and also what they are willing to do or try
3) Based on your conversations, propose one simple change that has the best odds of both being accepted, and improving things. If the team has lots of conflicts, pick something very small. If there is too much dissension, pick something you can do with just one or two others.
4) Then make the change.
5) If things go poorly go back to #1.
6) If things go well, propose the next thing from #3.
But without talking to your team, and without establishing credibility and leadership, no book, degree, or IQ, will be of any use to you as a project manager. Start with your team first and earn their trust.
P.S. The book was originally called The art of project management. Making things happen is the 2nd edition, and heavily revised, version of the book.
- Scott Berkun, Author of Making Things Happen
This guy wrote an amusing piece on Agile methodolgy.
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."
In post Patriot Act America, the library books scan you.
IMHO you need to get someone who knows what they are doing. There are project managers and there are successful project managers. You are not going to pick up a book and walla Project Management knowledge flows in.
Steve McConnell
My opinion? See above.
A book I warmly recommend reading is
Herding Cats: A Primer for Programmers Who Lead Programmers
(http://www.amazon.com/Herding-Cats-Primer-Programmers-Lead/dp/B001ULCL1Y)
IMHO the title says it all, it's funny and enlighten to read and gives a good introduction from the point of view of a programmer who slipt into PM. I especially enjoyed its categorization of programmers into different brands.
This is referred to in project management as the "Halo Effect", i.e. where a team member who is technically talented (YOU) is handed the PM role just because you're good at one thing and will naturally be great at another. Convince your company to hire a real PM...
Mod the parent AC post (#27677421) up, it's from the author of Making Things Happen. Genuineness based on him linking directly to it from his blog.
fencepost
just a little off
like pivotaltracker.com, if you are doing Agile-style work. As long as you define your goals properly (which, in essence, equals a definition of your project), then you can use your management tool to keep track of what is done, what needs doing, priorities, estimated times for completion, actual times used, etc.
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" or "velocity".
In agile methods like Scrum (see here http://www.controlchaos.com/about/) or eXtreme Programming you try to work in fixed iterations of e.g. 3 weeks (you can define your own length like 2 weeks or 4)
You put everything you can think about into a prioritized "to do list", often called "backlog". The customer has to prioritize. Your goal is to plan for the next iteration, usually called a sprint. Just take the as many high prioritized items from the backlog into your sprint.
After the first sprints you likely realize that you put always to much work into one sprint (the same would happen in a milestone but with worth consequences). The point is: now you get a feeling for your velocity. You can react on this by changing the sprint length (4 weeks, advantage: less overhead in planing, disadvantage: longer feed back circles from the customer), or by stuffing or by tools or by changing priority of features. The managers are now in the position to be able to manage.
In the long run you will have to break down items on the backlog in useable small work load items. It does not make sense to have one item with estimated work of 100 hours and 15 items with estimated work of 20 hours and 50 items with estimated work of 6 hours in your current sprint. One rule of thumb is: no backlog item should have more work assigned than 16h (I personally prefer 8h). If you have bigger items, try to split them. E.g. pan to "analyze" a certain problem in this sprint, assign 16h for use cases/stories/or what ever specification you use, 8h for architecture or database design, 8h for a rough code concept. Put the implementation of this into the following sprint!! So you can get feedback between sprints.
After a few sprints you will be able to put "the right amount" of work into your sprint and yout estimates on the items in the backlog become better. Remember Joh? Two sprints ago we estimated that tricky stored procedure to take 16h but we nearly needed a week for it. Lets better estimate this one on 20h instead!
The problem with milestone based planning and GANNT diagrams is: every work piece has an amount of time associated + a buffer. The buffer is always an uncertainty that is added so a chain of tasks add up their buffers. Starting times of tasks in the future are unnecessary far in the future, nevertheless buffers tend to get used up. Nevertheless there will be buffers that are to small, because the complete task was estimated completely wrong. Bottom line on a small GANNT diagram with 4 parallel _big_ work flows (like backend development, frontend development, database development, testing), all consisting of roughly 25 tasks (done in parallel or sequential) you have bottom line 100 task, all with a buffer. The likely hood that you reach your milestone in time is basically very close to zero.
I don't want to come to the conclusion that GANNT based planning does _NOT_ work, e.g. you can add also buffers at the beginning of the tasks ... but I don't want to go into this.
However in your situation you will be likely completely overwhelmed by simple tools like MS Project or other GANNT tools.
Regarding your question: UML is the right thing. It always is, no matter what other zealots say. The question is what kind of diagrams and with what kind of elements do you want to use? For the database ER diagrams might be enough, but what about "flow charts" (in UML called activity diagra
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
http://simproject.sourceforge.net/
Ummm, the Project Manager should NEVER say that scope cannot be added. That's not the PM's job nor their responsibility. Any changes to scope are the prerogative of the sponsor (eg. he who pays the bills gets to decide what is important). However, that being said, the PM should never factor any change of scope into the "plan/budget/scope" until they have received _signed_ instructions (formal or e-mail) from the sponsor.
Here is some generic advice that relates to any type of project:
1. Document everything and circulate it. Every meeting has brief notes and actions. All decisions are noted. Not everyone will even look at these, that's not the point though - these are are there mainly for you to go back into the history of an issue. This can be a lifesaver. Think about basic principles of QA as these apply to project management: document, document, document some more, and monitor.
2. Use hitlists to capture every pending action and set a due by date and an owner for that action is who responsible for it. This is particularly important for cross-team or multi contractor work, Archive closed actions. Google spreadsheets works well for this - the hitlist becomes the meeting record and automatically sets most of the agenda for the next meeting.
3. Someone needs to be in charge of the schedule, probably you. That needs to be reviewed with the stakeholders and team regularly.
4. Understand that the best laid project plans by mice and men will change in practice. Be flexible and adapt, be pragmatic. Don't get neurotically wed to your plan. Rigidity is death. Don't champion a lost cause or you'll be lost.
5. Be accommodating and allow yourself and other people space to fall into their best roles. Being overly territorial will go badly for you, since these roles in organizations can be subject to very complex political forces. Help move people away from what they don't do well, By the same token, you do it if you know you do it well.
6. When working with senior management, look out for their backs, know when to shut up and when not to (opt for the former whenever in doubt) and give their reuptations plenty of room to grow healthily, or they'll crush you like a fly. The best idea you'll ever have is the one they adopt and champion. Be expansive and generous with ideas with others though this is best done when your boss can hear it. By the same token be careful not to belittle colleagues, though it can happen even without intending it. People can take years to forget a slight, if they ever do.
7. Be proactive. See what needs to be done and start it. Get permission to do it if you can or need to, otherwise it is better to apologize than ask permission when something highly useful is at stake. Head problems off that you are responsible for before they get serious, if you can't then flag that these are coming in advance. Don't drop bad surprises on people in meetings whenever avoidable. Leave other managers problems alone at least in front of others (especially superiors), don't cross territory without discussing it privately first. Keep your team away from work that involves someone that doesn't like you, if they are nasty they may be setting you up for a fall, though for more senior staff this isn't usually worth the effort.
There are two major types of PMs
1. Generic PM - without any subject matter expertise (SME) - just a degree from PMI (cheap 45K-65k)
2. SME PM - same as 1 but with SME (expensive 85K-150K)
You need to decide where you want to go. Currently I am a PM with SME in Financial Market Data and currently contracting for $100/hr. But if I do PM work in a web/media company my rate will be $55/hr. - you see the difference!
Tools you need to learn.
1. How to write Emails - this is probably the most important thing in this role. Correct English and ease of reading is important - learn how outlook can help you on that.
2. How to conduct PRODUCTIVE meetings/conference calls
3. Learn Excel - you should be at the level where you know where and how to use PIVOT tables
4. Learn Microsoft project - I mean learn it very very well at the level where you can do cost estimation with it.
That's just the tools - since I can only tell you the skills what you must have. Then there are lots of books and people who you can imitate - don't feel bad, first you imitate, then you will have your own style.
Hope this helps
I wrote about using Use Cases and scenarios as a project manager without a lot of the involved UML. Works well for me. There are a lot of posts on various topics written by many experienced project managers on pmStudent.com...just use the search bar on the right.
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 engineers, designs, infrastructure, issues trackers, milestone releases etc.)
3. Identify risks and adjust the plan so that you have time to handle those risks (things like 3rd party bugs, engineers dying, hardware failures, requirements changing, performance failing, forgetting what needs to be done, the project team being incompetent etc.)
Repeat this until the project is finished. It's that simple. And that hard at the same time. Your job as a project manager is to continuously evaluate the state of the project and working towards a state in which you feel confident about the road ahead. If you do that properly, there's a small change your project will be a success. But to ensure success, you have to plan for utter failure.
0x or or snor perron?!
There are a ton of good comments here, but given your question -- and you seemed to sense this -- I would start with defining your objectives. Start with a high-level project objective, and then move into the spec phase. This will provide a clear roadmap for you or anyone else who needs to estimate the work as input into a project schedule.
A great post about specs was written by Joel Spolsky and can be found at:
http://www.joelonsoftware.com/articles/fog0000000036.html
Regards,
Dave Moran
http://softwareresults.blogspot.com/