Project management for non-project managers

A good site to visit is http://www.scottberkun.com/ The owner was a project manager at Microsoft and has written a very good book on project management. Doesn't spend a lot of time on particular methodologies but rather on concepts and reasons behind why things should be done.

However, if the person does not have the time to read the book, the forums and the PM-Clinic mailing list might be some help if the person gets in a tight spot.

Erik

I, too, mean no offense to Grasping. But my first thought was that perhaps someone is intentionally seeking to sabotage the project, ensuring its failure. Wouldn't be the first time. Grasping has additional motivation to succeed and show 'em wrong!

As PM consultants, we see this situation all too often; the unsuspecting employee thrown into a PM role with no training or experience. Your three concepts are a great start. I want to provide just two more ideas, if I may? These can not only save some grief, but also fulfills the CYA aspect of this assignment.

First, look very carefully at the tasks which depend on other tasks within the project. Get target dates from those doing the work on these tasks and write them into a chart (you can use a standard spreadsheet for this). Not only will this make visible those important tasks to both management and the team, but it also provides a very basic "critical path", or those items which must be completed that determine the minimum length of the project.

This brings me to my final point. At least a passing "risk assessment" needs to be documented. Things to listen for from the team are "we've never coded anything like that before", or "I hope we can hire a DBA in time", etc. Simply flag these high risk items in your plan, and spend a little time thinking about Plan Bs, should your original task not get completed for any reason.

With these five concepts together, you now have considered and documented those items which any PM worth his or her salt would have done and made the key taks and risks visible to all.

Good luck!

Larry Alexander
President
Project Resource Associates, LLC
http://prallcorp.com

Software projects have unique challenges that go beyond general purpose project management as well.

You can also check out my blog. It's purpose is to provide advice for software projects specifically. It covers some of the software project killer factors that throw most software projects off the rails, and how to manage them.

Uncommon Sense (for Software)

Craig.

As Larry Alexander pointed out, risk management - do it every day. Think of it this way - if you can deal successfully (easier said than done) with all the risks, you're going to succeed.

Consider Scrum as a project management methodology. If you can sell it or adapt it to your situation it should be a big help. It's much easier to grasp than classical (PMI/PMIBOK) project management. It provides a clear relationship with stakeholders. It provides an efficient reporting structure. It simplifies many planning and reporting tasks (let me know if you'd like a copy of the tool we use). It won't make you an instant experienced project manager, but it will likely improve your chances and your learning curve.

And, in case you're not already cowering in a dark corner, beware of how you take on any non-project manager work. From your description, I'd be wary that yours is the kind of organization that might explicitly or implicitly expect that adding the PM role doesn't take away any of your individual technical contributor responsibilities - guess what you have two jobs! Even if this is not the case, most people like doing what they are successful at, so even if you aren't expected to still do other stuff, you're going to want to help out, and typically you'll find that the PM (guess who!) and the team need the help. Just remember that the PM role is more highly leveraged than the other stuff and should [almost] always take priority.

You might want to visit my web site, Bluejeans Place, at www.bluejeansplace.com and check out my project management pages. You may find the Work Breakdown Structure (WBS) I created as a study aid for the Project Management Professional (PMP) exam to be helpful as it is (1) based on the Project Management Book of Knowledge phases and processes and (2) uses a simple ERP installation (don't laugh until you look at Note 1 in the WBS) as an example. The WBS was produced in Microsoft Project, so you ought to be able to download and view it fairly easily.

There's also a professional paper posted on my site's PM pages which deals with the issue of how to define good requirements questions. I suggest you read it through and think about using "decision tree logic" as you try to determine the business needs (pain points), the requirements (the things that need to be done by your software product) and the specifications (how fast, interface with what, etc).

You may also want to write a short memo, to be later incorporated into a project charter, between your manager and you which clearly and simply states:

1. The scope of the project includes A, B, C, and D.
2. The deliverables of the project are 1, 2, 3, 4 ...99.
3. Anything not included in the scope (Paragraph 1) and not provided by you as a deliverable (Paragraph 2) is out of scope for this project and requires a change order impacting scope, schedule and resources. (This keeps you out of the Christmas tree problem where people want to keep hanging extra "little" things onto your project and it never ends.)

Good luck!

Pat

Although Bob's three points will get you through the first meeting or two, you must make the time to learn about project management (PM) as it may consume your next few months and will have an effect on your carreer.

A couple of questions you will be asked constantly by the business managers are: "Why isn't Mary coding yet?" and "Why can't this project be done is just X time?". So you'll have a lot 'splaining' to do.

I recomment you check out http://www.construx.com. It is Steve McConnell's site and he is my guru on PM. Of all his wonderful books, the most condensed one for the situation you are facing may be Software Project Survival Guide (Microsoft Press, 1998, ISBN: 1-57231-621-7).

-Eduardo

Great answer Bob, except for the discouraging attitude. The three points are an excellent place to start.

Everyone has to do this the first time. Some of us have the luxury of working for consulting groups and having "methodologies" burned into our brains. Others have not. Grasping figured out what he doesn't know, which is the first (and biggest) step to getting past it.

As a techie turned PM, I would say one more thing to Grasping. Installing MS Project does not make one a project manager. It is far more about communication and organization than about mastery of the technical details. If you can get past that, the tool and methodology choices are less critical.

Been there - done that - good luck! I was a customer service rep for a big telco who was put into a PM role with a huge, important government project. It was insane! One day I was taking calls to install phone lines, a couple weeks later was in the field at a construction site "consulting" with construction engineers on cable entrances.

There was ZERO training. It was entirely by the seat of my new slacks. What got me through this and many other boggling jobs was immaculate organization. This was 15 years ago. There was no MS Project, only 3-ring binders and plenty of paper. I filled many shelves with full binders of working and completed projects.

Every big job is really a series of small jobs. After you study the big job and get some idea of its objective you can begin to isolate the smaller jobs, some of which further break down into even smaller jobs.

Don't even try to understand everything at once. Get the parts you do understand underway and some of the other pieces will begin to fall in place, too.

Don't put off the incomprehensible components. Remember, other people not as smart as you have done the work before, you can too.

Do call in your experts to do their work. You are a project manager, not an engineer, or other specialist in this role. It is your job to organize their objectives. Even you have their skills, don't do their work for them. That is their job and livelihood. Your job is to keep them happily employed. If you do their work you are doing them no favors and will build resentment.

Keep copious notes. I recommend doing this on paper for the most part, or printing out what you are working on on computer. When situations get tense, and they will, there is nothing like browsing real documents to clear things up. Don't trust anything to memory - not any task, to-do list, work assignments, etc. Write it down.

Keep a to-do list where you can write down every task with a reference to more detail elsewhere. Check off the tasks you complete. Review this list daily and keep it fresh. It will not only help you avoid forgetfulness and procrastination, but will give you much needed satisfaction as you see the list grow shorter.

Again, good luck!!!!