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.
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.
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
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!
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?
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.
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.
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
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.
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://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
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.
ACM offers many online courses in project management. Most of these are free to members.
I personally really related to these, as I'm a software guy with a Mechanical Engineering degree...
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.
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.
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.
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.
I don't think you're doomed. I would agree that things are indeed hairy, but any sort of organization and process you can bring to the table at any point is only going to help you. At the very least, it's going to let you triage your current state and figure out what to cut and what's just not doable and able to be punted to a 2.0 release. Baby steps.
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?!