Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
most of the books about Project Management (if not all of them) describe management of one big project. Sometimes they describe how to manage very few projects in the same time. But I have very different situation.
I manage small team (4 people) with very small projects. Usually one engineer works on dedicated project. Some times One engineer work on few projects with different priorities (projects quite often switched to "on hold" state for a several days).
So my specific is:
Small projects with short lifetime (1 week to 2 month in general)
Projects usually are not shared between engineers
Number of projects can be 2-3 times higher then number of people (some projects go "on hold" quite often)
There are 2 longterm projects with lowest priority which can be shared between engineers
Can someone share own experience how to manage projects like this, or if you never had such experience but have an idea how to organize that I'll be glad to read it.
Of course if you know book which can help me - I'll be glad to check it as well.
May be there is ready methodology for thas kind of projects which I never heard.
Thank you.
I suggest looking at Kanban. Here's some links to explore:
Kanban (the book) on Amazon
David Anderson's site
Some Kanban info on InfoQ
The Limited Work In Progress Society
I have a team with this situation. My solution is to run each project with week long iterations and allocate an engineer to that project for a number of weeks, where possible. That way each project is only an average of half a week from being worked on if needed.
If you have higher levels of concurrency an alternative strategy would be to keep the short iterations and to set objectives for each iteration that include aspects of each project that requires attention. Multiple, concurrent burndown charts could be maintained to track the work for each project, but I would suggest these are a little academic if you aren't going to have effort expended on each project at a consistent rate. Using this approach would be unorthodox but would give you quick feedback, regular delivery of working software and progress on all the projects that need it so shouldn't rile the agile evangelists.
If you're stuck with this setup, the other responses give some reasonable ideas for dealing with it.
But this is a bad setup, and I'd advocate trying to change the situation. You have too many simultaneous projects, and a work process that doesn't allow teamwork.
If multiple projects have the same stakeholders, try to get the business to merge the projects. If this can't be done, or if it still results in multiple simultaneous projects, try to get the projects to be prioritized by business value so that you can put the whole team on the most important project, finish and deliver it and then move on to the next most important.
This will almost certainly involve getting people outside your team to make some difficult choices, and may be politically difficult, but there are gains for the business, which might help you with selling the change.
Getting a project out the door and in production more quickly will improve the cash-flow/throughput of your company. See throughput accounting.
Putting the whole team on this one project will reduce the impact of a developer absence (see bus number) and will mean your team is actually working as a team rather than as a bunch of individuals who happen to have the same manager.
If you can't get the business to prioritize down to one project at a time, by all means try for two, but with a team of only four developers, you should be doing one.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
Currently we are facing some problems with our Team Lead regarding work assignment hierarchy and responsibility of work done. It is generally seen if some targets are not met by the team the Team Lead openly starts blaming the team and sometimes pin-points some of the developers. Further during the allocation of work to the developers the Team Lead does not properly explains the work to be done but expects us to complete it completely.
The worst part is that the Project Manager and Team Lead are real cousins and the Project Manager always takes the Team Lead side when such issues are put up to him by the developers.
Please guide what best can be done by the developers to make a healthy work environment.
Thanks in advance.
This is double sided, and very objective. It might depend souly on what kind of person the Team Lead is, and if they are open for discussion/questions.
The team lead should be openly addressed about this, BUT also, if a developer is unsure about what to do they should ask.
It never hurts to ask questions, you will be amazed at what you can learn.
Well personal relationships should not not be related with professional life. The developers should first of all organize a meeting with team lead and put forward their issues in a healthy and explanatory way. Also keep in loop the Project Manager with your views. Do not wait for anybody to make a healthy environment for you... start yourself in this direction.
One should be able to adapt to various environments and culture that is different in different organization. Always be with the flow.
I'm not sure that you can avoid conflict! The challenge is deciding what to do so everyone can learn and not too many people get hurt.
A well-run team should run itself. That is to say, the team lead's role should be to get a good framework in place so the team can decide on priorities, techniques, methodologies and even process by talking together.
So good managers will ask team members "OK, so what would you do?" They'll then get the appropriate support put in place so that can happen.
I'd suggest that as a group you
Regularly get together (perhaps weekly) to review progress and learn from mistakes made in implementation.
Make sure that all tasks are given to the team as a whole, not to individual developers. Everyone should know the high-level summary of a job.
Get together daily to very quickly summarise progress. Keep this meeting limited to 10 minutes.
In these meetings it's best to avoid blaming people. Blame the code instead, or the process, but don't get personal.
And if your company culture allows it, try reading up on some of the literature around agile project management: there are many parts of that process that are designed to avoid conflict of this nature. However, it can be quite a hard shift for some organisations to devolve quite so much power to developers...
If possible, schedule a meeting with the Project Manager and Team Lead. Openly discuss the issues in a mature and positive light. Tell the Team Lead what you do like (as a group), and tell him what you think can be done to improve quality, expectations, deadlines, etc. If critical requirements are habitually missing, let him know that. Although his cousin is the Project Manager, his answers may be guarded and he could get defensive no matter what the real circumstances are.
Ultimately, in my opinion, the PM/TL relation is a formula for disaster. If the problem is the Team Lead, and the Project Manager is part of that problem, then the next logical step is to go to the PM's boss.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm working on a software project which several members are working from home and some other are part-timers. We meet physically one time each month at least. We communicate mostly by emails. Our source code repository (mercurial) is on a jungle disk (workgroup) that we share together.
We have a working product and one customer. But, we are not agile enough (ie: one change in the code sometimes break something else, we don't have unit testing, code is not documented, etc.) I want to use an Agile methodology to coordinate our work and track our progresses. I also want to use TDD.
The team has no experience with agile methodologies (or other methodologies).
What is the best approach to use an Agile methodology with a geographically distributed team? Which methodology is best with that kind of team? How to implement it efficiently with the least resistance possible?
Thanks!
I have done this as part of a distributed XP team sharing source code and stories across 3 sites, each site being 12 hours apart (Seattle, Bournemouth UK, and Singapore).
Here are some write-ups of what we did:
Distributed Agile Patterns: http://www.keithbraithwaite.demon.co.uk/professional/papers/index.html#europlop2005
http://www.keithbraithwaite.demon.co.uk/professional/papers/index.html#xp2005
We found that it helps to get everybody physically together at the start of the project to establish standards and to build relationships.
We also found that it helps to have "ambassadors" - shipping different people around between teams to spread knowledge and build trust.
We were lucky to have three sites that were each 12 hours apart - so we could have a stand-up meeting first-thing in the morning and last thing in the evening. We called them "hand-over meetings" and did them over video-conference between the incoming team and the outgoing team.
We also found remote pair-programming worked - between a local pair and a remote pair (i.e. four people) but that it's very intense and draining and best done only for short periods of time when it's really critical to see what other people are doing remotely.
Aside: Kent Beck's Advice for people using Eclipse to remote pair: http://www.threeriversinstitute.org/blog/?p=584
Well, my first thought, given what you specified:
Add unit tests to your source code!
Without unit testing, most Agile methodology isn't all that useful. Being Agile is about being light and being able to respond to change quickly - unit testing is one of the main things that makes that work. Without unit testing, you'll never have the freedom to make changes without risking major breakage.
As you add tests, I would document your code. This, again, is critical for being able to change things, even more so when the team is distributed.
Once that's done, you can start implementing other methodology over time. Personally, I would have the entire team do this, and get started on having daily/weekly stand-ups (which work fine with a distributed team via conference calls, etc), where everyone describes what they've tested, how they're progressing, etc.
That will at least get you on the proper track...
Have a quick browse through this blog:
You're not agile if your team is dispersed. Yeah right!
Start with a Continuous Integration (automated build). I used CruiseControl.Net. I had two builds set up: 1) an automated build after every check-in and 2) a test build to build on demand.
You have to improve your communication for a start. Yes, engineering practices are important, but the key to agile is communication. Email is not the most effective tool to coordinate an agile project, but there are not shortage of tools out there that can help.
We have had great success with Skype (mostly pm, but also normal phone), and also with tools like MS SharedView it is possible to demo and even pair programme across sites.
Once you start to communicate effectively and feel like a team, the rest will follow. Agile is all about inspecting and adapting, so try things out and have fun with it. Start with the daily stand up and move on from there. Regular retrospectives will help you identify you problems and improve.
If you are into tools: To be able to do pair-programming or synchronous code reviews remotely, you could try the eclipse plugin Saros, which enables collaborative editing (including support for driver/observer roles and following users through the code).
(Disclaimer: Saros is a project of my working group at Freie Universität Berlin)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
As a professional programmer I work daily with a species known as the "PM". While they usually go by that common acronym, it seems there are actually several discrete varieties: product managers, project managers, and program managers. There may be other species yet undiscovered. Through years of close observation and study, the subtleties of their differentiation elude me. I have only been able to determine their common responsibly: to communicate to me, the programmer, in the vaguest possible terms, what it is they think they want built. I then tell them, in the vaguest possible terms, when I think it will be delivered, and they go away.
So my question for the stackoverflow crowdsourcing juggernaut is this: please explain the differences between the product managers, project managers, and program managers. Please do so with out waving your hands, as I can not see them, and it doesn't help anyway.
I'll attempt to explain them as I've worked with them. Please do understand that the definitions can be murky and change from organization to organization.
Project Manager: Responsible for coordinating the schedule of the project within the engineering. This should be the one single person that management can go to in order to know the current status of the committed work for a given release. This person is typically hip deep in spreadsheets, Gantt charts and status meetings.
Product Manager: Responsible for the deciding which user-visible features will be on the plate for consideration in a given release. This person should be well versed in what the customer is attempting to use the software for and be able to act as a developer's resource for understanding what to build from a functionality point of view.
Program Manager: Essentially a project manager responsible for coordinating the release across the different disciplines in a company. This is the person who makes sure that marketing has the press release ready at the same time as engineering is ready to ship and that sales have been trained on the product.
These are how the last couple of companies I have worked for have defined the roles, but you will certainly see many variations.
Project Manager a person responsible for managing project, specifically its scope, quality of deliverables, deadlines, time spent, and budget. PM bears responsibility for all project deliverables. See my other answer for a drill down on PM responsibilities. On small projects PM wears multiple hats, but during bigger ventures may have others to help her (or him), such auxiliary jobs might carry the titles of:
Project Co-ordinator is someone who co-ordinates project work between various parties involved and individual stakeholders.
Project Administrator keeps reporting up to date, including project status, does all kinds of other administrative tasks.
Project Expeditor does exactly what the title says: chases everyone up, removes obstacles from the project team’s path and makes sure there is always steady progress.
Product Manager takes responsibility for a product and full product lifecycle. The products are normally created and evolved through a series of projects. The relationship between products and projects is many-to-many. A single project may contribute to many products’ evolution and a single product requires several projects to keep carrying it from one lifecycle stage to another. It’s also important that product lifecycle constitutes a series of states (such as “shipping the product” or “supporting the product”) that are usually carried on as processes and state changes done as projects. Read on the difference between a project and a process.
Program Manager manages a series of interdependent projects aimed towards a common end. Some of the projects are executed in parallel, some sequentially. Program Management is fairly similar to project management, where individual tasks are replaced by entire projects. Think in terms of the space exploration program.
Obviously these titles are not set in stone and companies would often attribute a somewhat different meaning or completely redefine them. The definitions I’ve given are generally accepted within the management community.
Rather than focussing on subjective definitions of each of these roles (yes, they are subjective and you’ll get 10 different answers from 10 different people), I would focus more on the task responsibilities of the individuals. A tool to help you with this is a RACI matrix (aka responsbility assignment matrix) which makes it clear who is responsible and accountable for activities.
This industry will go on creating new “manager” titles forever and a day. As far as I’m concerned, just tell me what they actually do upfront in the project then we’ll refer back to that whenever there is ambiguity.
I read in the book (the title eludes me, but it has "Management Anti-Patterns" somewhere in it) that PM are usually developers elevated to a manager role, but who has no idea how to manage. And still developers want that role because that is one step up the hierarchy (and a higher pay bracket).
A good developer does not necessary means a good manager, and once you become manager, you got pressures coming from your peers and from the top, and some cannot cope with it. Some companies are 'enlightened' enough to develop a separate career track for developers and have their pay match those of the managers.
I'm sure you come across one of the more introvert species of PM. The last time I was in a mock PM situation (it's a software engineering module which we have to do paperwork, like SCRUM) I was chasing my team-members for updates every week and doing code reviews. So that's one perspective for you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Or they (team members) need someone to keep pushing?
Edit:
The above line was supposed to be sarcastically funny. Sorry to throw you guys off.
I am talking more in the lines of distributing that work within the team, and not having one person assume and/or perform project management activities.
You may not need a project manager as an exclusive role (depending on the size of the project in question) but you do need someone to track activity and make sure everyone is reaching their objectives, and assign extra resources to bottlenecks. In a large project, this is a full time job, and you would need someone just for that. In smaller projects, one of the team members can do this in addition to their other contributions. Of course, the project manager is, in fact, a member of the team, but I assume by team members you refer to the computing group.
Its definitely doable, if you have a team that self polices itself. I've worked on projects where the team seemed to be more in tune with the time lines than the manager...
Also, I'm sure that there are plenty of examples small/medium size open source projects that get released without an official project manager.
depends on the team, and how they work together
i've worked with agile teams that self-organize, mutually-motivate, and deliver promptly, all with no project manager
i've also worked with teams that had project managers, business analysts, quality assurance teams, network administrative teams, database administrators, et al, that delivered late and with less than optimal quality - mostly due to the "can't say no when the client is your boss" factor
Can they: Yes certainly. There are particular personality types that will work on time with little or no supervision.
Is this a good idea: Probably not. The type of people who are going to function at a high level in this type of setting are very few and far between. Once you have more than 2-3 people working on a project you will start bringing in people who need supervision. At that time a) one of the programmers will become the defacto project manager, b) the person will not contribute to their full potential or c) you won't ship :)
Yes, at least to some degree, as I explained in my recent Meeting-avoidance for self-managing developers conference presentation.
It's less about pushing and more about planning the way forward. Somebody has to figure out what order things are going to be built, what the dependencies are, what resources are needed, etc. If it's not done by a dedicated project manager then the team will have to do it themselves.
It's possible.
It's just not very likely.
However a bad PM can definitely prevent a team functioning predictably and delivering on time.
I think it's likely the team will arrive at a destination, but with no acting PM or PM, who knows what that destination will be.
The PM keeps people on target, on schedule, and then adjusts when the target moves and the schedule is missed. Relying on a team to group communication is probably destined for trouble in more cases than not.
It depends on who are the members of the team. If the team is filled with newbies or bums there's no future for the project, but if it's got motivated programmer who are focused and respect their goals, they can deliver more than what's expected.
Take Jo Peabody for example, he employed a team of programmers, let them run amok and earned some million dollars (At least that's what he claims in the book he wrote after he became a millionaire from Tripod). The book was 'Lucky or Smart'
So like I said, it depends on the team.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
As a contractor, out-sourcer and shareware author,I have about 5-10 projects going on at any one time. Each project has a todo list, requirements need to be communicated to other outsources and employees, status needs to be given to clients, and developer's questions need to be answered.
Sometimes it is too much... but then I realize that I'm not very organized and there has to be a better way.
What is your better way?
How do you keep track of requirements for multiple projects, assign work to multiple developers, obtain and give status for multiple projects to multiple clients?
What tools do you use? What processes?
This may sound really old-tech, but a different set of notepads for each project. Now, hear me out.
I know that notepads aren't searchable, and they aren't indexed, etc. But they will have meeting dates and times (if you've been taking notes during meetings, even on the phone), they have the ability of never crashing, and they're future proof in the event of wondering what you did a few years back but can't remember if the old project files made it to your new hard drive.
But the biggest reason is CYA-- logbooks and notepads can be used in the event of someone suing you as legal documents, especially if you've been diligent about dates. It might also work during patent discussions as well, showing a clear date and time of ideas being made. During another life, I worked in biology labs, and electronic record keeping, because it's so fickle, wasn't allowed for the legal reasons of being able to show that the work you did was your own. That attitude has permeated my own project notetaking, and helping to keep track of everything I need to get done.
You should have a look at No Kahuna Easy to use; Free and Pay versions; active, responsive development team.
tools are not the answer, unless you already have the knowledge, organization, and self-discipline to use them well. i highly recommend Getting Things Done
I'm a big fan of http://trac.edgewall.org/'>trac for managing software projects. It provides task and bug management with integrated wiki and source control.
We have been using FogBugz for managing several projects (10+) and clients (20+) for more than 4 years.
We have a project for each product and another project for each client. In this way I can control the requirements for each product and the pending activities related to each client.
Try Omniplan if you're on a Mac. I find it just makes sense. I also find I don't end up fighting the interface and instead concentrate on using it to help me plan better.
Edit: It goes well with OmniFocus and no, I don't work for the Omni Group :)
If you are into Agile methods (or even if not) you could try some of the Agile tools out there. Look in http://www.agile-tools.net/ for some comparisons. I use xplanner at work where we coordinate requirements and work over iterations among several teams. It has its quirks but it generaly gets the work done and allows for some useful agile structure. I am sure some other will have preferences for more mature tools.
Trac (as Mark Roddy mentioned) is also nice, because it integrates a wiki, task and defect management, so it can be an interesting tool if you have none of those already in place.
I should say that we use Mantis now, but I wish it was better. I wish I could use it for customer-facing queries, I with I could open and assign issues by email.
ScrumWorks Pro looks promising, but amazingly expensive for me, with 15 developers.
AccuNote may be an option, but it is new to me
I'm using the customer support, project planning and issue management portions of OpenERP. Having your issues and feature requests, along with the tasks required to get them done on the same CRM that allows you to manage your customers is a big benefit.
I have used SourceGear Vault to manage all our software projects. Our business nature is very much driven by project basis - typically I have 5 active projects running at one period of time.