first time managing a project

Hi, I just got chosen as 'project manager' for our next project. It seems like most people feel 'sorry' for me around here... We are designing a moderately large mostly digital asic and the team consists of about 6 people. I've never managed anything before and most of the people in the team are more senior designer than me. Right now, things are decided from hallway conversations, and nothing is really written down in terms of schedule and who-does-what...

I wonder what tools if any that people use to manage a project. Is something like MS-Project any good? I understand that the schedule we would put in place will never hold, but I figure it's better to have something than nothing. Also, what do people use to track down bugs and issues. The chip is divided in 6-7 blocks, each will be assigned to one-two person. Where should I gather the information coming out of the weekly meeting - schedule slip, bugs to be fixed etc...email? ms-project? hallway?

Thanks a lot,

Dave

Reply to
gretzteam
Loading thread data ...

MS Project is a worthwhile tool but to use it effectively you need to use it a reasonable amount. If like me you end up doing a bit here and there it is always a bit of a struggle to find the feature you want. Whatever you do you are it is best to break the job into manageable chucks with some kind of sub-task target to run against. When breaking down your sub-tasks think of things that mean that things don't happen as fast as you think. Lack of staff interaction during summer and christmas holiday seasons (sods law -they never take holidays at the same time) is one common event to think about. Usually I think up a time to do a task then multiply by 3 and that usually comes in about right normally.

John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board.

formatting link

Reply to
John Adair

If you haven't managed a project before it might be better to avoid the hassle of a new tool such as MS-Project and simply model it on a whiteboard until you get comfortable with things.

And get yourself some training in techniques of project management (not tools), including the soft skills.

Alan

Reply to
amyler

I agree. First get the project management skills developed, then worry about the scheduling (which is only one part of the project management).

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

I'm not sure what "project manager" means at your company, but if you can't fire anyone you're not a manager. If someone calls you a manager, with or without the word "project" in front, holds you responsible for results, but doesn't let you hire and fire then you're not a manager, you're a future scape goat.

If you're lucky you won't be held responsible for schedule slips &c. If you're not lucky then the piece of software you most need is your friendly local word processor, for resume composition.

As mentioned elsewhere, you want to understand project management skills before you bother getting the tools. If you can't do it with index cards and magnets on a whiteboard then you can't do it with Project. When that poster mentioned "soft skills" he meant the people skills to manage your troops _and_ the political skills to get the resources you need to succeed from your superiors. This cannot be underrated -- I have never known a truly successful project manager who could not get what he needed from higher-ups, nor have I seen one who could not get people to do what he felt was necessary, even if no one else could.

Enough of that.

However you manage your schedule data, you need to have a solid estimate. I've found two ways to accurately estimate a project: wideband delphi (do a web search) and looking at how long it took to do the last project. The second option only works if you've done something similar; wideband delphi is very accurate but it takes a long time (it also refines the project definition, so you can call it "preliminary design" if you can get people to cooperate).

No matter what, if you track the actual schedule against your original estimate you can at least have an estimate of when you'll actually be done. Not only can you use this estimate to motivate the troops, but you can use it to warn your boss that things aren't going as fast as expected.

Track bugs with a data base. I prefer a real honest computerized database, either a pre-written package designed for bug tracking or a custom application written on the data base of your choice. At any rate you need to be able to track the progress of bug fixes and feature additions from cradle to grave, you need to know whether they are newly discovered, who's currently responsible for them, whether they've been fixed, whether the fix has been tested, and if they've been put to bed. I'd start with a purpose-written application, if I could find a good one (do a web search).

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

Hi -

First off, I've got to commend you for asking this question. Lots of first-time managers don't realize they need to build a skill set until after their first project. Good for you.

I can't answer all your questions, but here are a few comments about maintaining schedules.

Maybe it's been improved, but after my last experience with Microsoft Project in the mid-nineties, I vowed never to use it again. Granted, I winge and whine about all MS tools, but Project has got to be the least intuitive, most time-consuming tool I've ever encountered (and I'm including CAE tools in the mix). You want to spend time refining the schedule, not learning the peculiarities of the scheduling tool.

Try to use a simpler approach, if you can. Joel Spolsky recommends using Excel; the following article may give you some ideas:

formatting link

After my experience with Project, I went on the lookout for simple scheduling tools that weren't sophisticated enough to keep trying to "help" me. One that I've used successfully is Kidasa Milestones

formatting link
which costs $60 and, to its credit, does very little compared to Project.

Finally, one engineer I worked with a while back made what I'd consider a key insight: the most important items on the schedule are the transfer points, i.e., dates on which you transfer work to someone else, or someone else transfers work to you. You can tell they're important by observing how much effort people put into trying to avoid filling them out on the schedule.

Bob Perlman Cambrian Design Works

Reply to
Bob Perlman

How well does that work?

I'd expect it would give horrible results in two common cases. (Maybe just looking at the same thing two different ways.)

One is the one-last-bug problem. All the module tests go great but then it doesn't work when you put it together.

The other is that halfway through a project, the nature of the work changes. You shift from writing code to integrating/checking. Knowledge of how well things worked during the first mode doesn't tell you anything about how good your estimates for the second mode will be.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray

Watch out for "feature creep" also, i.e. requirements / specifications changing as you're going along.

How you handle that will probably be make or break for your project. It's a very difficult tightrope between frustrating the people who are waiting on your chip (regardless of whether it's customer specific or mass market) by playing hardball with a formal change request procedure, or frustrating your team by agreeing to spec' changes without agreeing schedule impacts arising from those changes.

Doing project management can be very challenging, keeping all those plates spinning in the air at the same time, but it's very rewarding when you hand over the development at the end.

Don't take it personally if the development gets canned, it happens a lot in our industry. I've never seen a bad project manager be the root cause of a cancellation, it's usually external like missing a market opportunity or whatever. In which case you can pin it on your product marketing people (or your top-management, or your end customers) for being too far behind the crest of the wave.

Last word, but in my personal experience I think women make better project managers, as they're naturally gifted multi-taskers, and usually have better sift skills than typical male engineers. Not always, but on average.

Alan

Reply to
amyler

This is a common issue to all of us, and due to poor specifications. Engineers (and management) hate the time to put down a thorough specification 'because we could be actually implementing something', but when modules don't work together because they did *not* do a thorough spec, it takes longer and is far more frustrating, to say nothing of being hazardous to your current employment position. One of my cardinal rules of project management is --Have a thorough specification of the task--. Thorough spec: Any three of your engineers can read it and **will all get the same result**. If three different engineers read that spec and do not agree on what it means, it is not a properly written spec.

True enough. I usually allow a fair amount of time (depending on who, what etc) for 'mode changes' Product definition Spec writing module implementation Integration testing

Each of those is a major section and should have some time between them for the team to 'change focus'.

Your projects may have more stages for good reasons. I have found this is the minimum for my projects, so far.

Cheers

PeteS

Reply to
PeteS

The first training I got in PM was ETP's 10-step approach :

formatting link
For software-specific projects I've found Steve McConnell's ideas helpful :
formatting link
Another consideration is PMP certification wiht PMI :
formatting link
Overall I'd agree with other posters that tools are far less important than process and attitude. PM has many angles, cost, scheduling, quality, etc... Don't neglect any of them. One apprach is to consider you (the PM) being pulled in 4 different directions - scope, quality, time & cost. You (and your stakeholders and team members) need to appreciate that those 4 all are factors. E.g., if you increase the scope and the other three constraints remain the same your project will fail.

Brendan

Reply to
Brendan Cullen

Absolutely, Fergus O'Connell / ETP teach a huge amount of common sense.

Alan

Reply to
amyler

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.