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.
Related
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.
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 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 3 years ago.
Improve this question
Situation: A team is currently working in the same office. Due to reasons unknown to the team members, they will have to be split up to work on different offices.
What are the possible obstacles for the project if team members are geographical far from each other?
Communication. Period.
It's surprising how much slips through the cracks when you can't walk over to someone's desk and ask them what the decision was on item X. Someone needs to be put in charge to ensure everyone is on the same page. Email is not going to work. People don't get CCed, subject lines get all confused and a huge design decision can be affected by the tone of some obscure line.
Set up a central website location where all communication runs through. Phone conversations should include everyone or no one.
No blackboard :(
Apart from the fact that communication is obviously more difficult, there can be a time zone problem.
For example I once worked on a project, where part of the team (on which I heavily depended) was in Novosibirsk(GMT+6) and I was in Moscow(GMT+3). So, when the guys at Novosibirsk came to work, they had to still wait for me for like 3 hours. In the evening, if i needed something terribly important -- whoops, no luck, they are already home and sleeping, have to wait for the next day.
Add to that the fact that we had lunch at different times and we ended up with 3-4 hours a day when we actually can communicate using VoIP or IM.
The company ended up moving those guys to Moscow eventually.
Bandwidth when exchanging info face to face or being in the same office is several orders of magnitude higher than when using a combination of instant messaging, wiki, issue tracking, phone, skype and screen sharing.
It's also much more difficult just to initiate the exchange of info when in different locations geographically.
I hate to have to say it, but accountability can be a problem, particularly if the team's manager is also remotely located. I've found this to in general be less of an issue on development projects and more of an issue when looking at IT & support teams, particularly when end users bypass issue tracking and help desk systems.
Questions/Decisions pertinent to the domain when the lead/architect is in a different TZ.
Billage loss when someone is held-up on a task/bug because of the above
Code breakage when someone in another timezone commits, and nods off ( Yes, it has happened )
Like Spencer said, a central wiki ( we use confluence ) helps a great deal. Integration Servers, Well defined build rules, VCS scripts (+: all play their role
It boils down to communication, though...
Off the top of my head -
The developers should have more than 2-3 tasks assigned so the day is not wasted when they can not proceed on one task.
The Lead should be able to define tasks with sufficient granularity.
Allocate closely Linked tasks ( preferably ) within a particular timezone.
Get the architect to post documents with enough detail ( Get the newest member on the team to review the document, along with one senior )
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 11 years ago.
Improve this question
In the course of my career I've noticed that developers working on new functionality are, as a rule, more cheerful than these assigned to troubleshooting and fixing bugs.
Good tips on keeping business support a happy? Organising business support in the way that team's morale isn’t hurt?
If we start with the assumption that the reason for new function developers being happier is that they get to feel proactive or in control and the troubleshooters are reactive and pushed around by the users one answer comes to mind:
Create a model for those doing troubleshooting to fixes to generalise these from point fixes into broad, consistent fixes for a class of problem. This puts them in the situation of creating new code, even if not new functionality, and they get to think a problem through and anticipate and avoid problems rather than playing whack-a-mole.
In fast moving environments it may also be possible to rotate people through the job descriptions by have them follow their feature from new development into fix and realease and hopefully into version 2 of the feature.
Our organisation has a substantial amount of support work and we've got hit with this problem really hard. The motivation on support teams could dropping down exponentially over the time if you don't do it right.
The principles which worked for us were:
Choose the right people. Some people are happier doing new stuff. Some people are actually much more suited to a steady no-nonsense job. It means that you should have two teams - one for development and one for support. Developers only stay on a completed project until they pass their knowledge to the supporters.
Choose the right leader. Good organisation is make or break here. A good leader would help to organise good relationship with the product users and at the same time will care for his team.
Rotate. We try to keep the support people on the project for a period of less then 2 years and then move them to something new. This helps maintaining proper morale and ensure that their skills don't rust.
Relationship with the customer. Make sure that the support team know how valuable they are. The customers/users should occasionally visit the team or the team should go on-site to have a face-to-face session with the users (a friendly dinner or lunch will also help)
I have seen this too.
There are few approaches that I can think of:
1. Give some thought to selection process.
Not everyone have same career aspirations. While some people are always dying to work for the latest technology and challenging projects, there are others who are content at a stable work environment. Picking the person with right KSA (Knowledge, Skills, Attitude) is always central to good person-job match. In this case, you just need to put more stress on the Attitude part.
2. Choose the right lead
Team leads play crucial role in controlling the motivation and morale of the team. There must be an open and frank channel of communication with team lead and upper management. Ideally a person from the senior management should be made the owner of the team in formal organization chart. Team lead should actively try to foster a team-culture that suites the nature of the team.
3. Rewards
Rewards off course are key tool for managing motivational issues. Just make sure the person receiving the rewards understand that the nature of job was also taken into consideration in decision to reward. If this point is not addressed, it is likely that the person will not take this factor into account when perceiving internal equity.
Following Bell's suggestion, consider letting new or junior developers cut their teeth on fixes. Promote them from maintenance to the feature team based on their performance and ability.
Healthy competition is also a good motivator, but it must be managed to remain a positive influence.
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.