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
I got into a mini-argument with my boss recently regarding "project failure." After three years, our project to migrate a codebase to a new platform (a project I was on for 1.5 years, but my team lead was on for only a few months) went live. He, along with senior management of both my company and the client (I'm one of those god-awful consultants you hear so much about. My engagement is an "Application Outsourcing") declared the project to be a success. I disagreed, stating that old presentations I had found showed that compared to the original schedule, the delay in deployment was best measured in months and could potentially be measured in years. I explained what I know of project failure, and the studies and statistics behind failure rates. He responded that that was all academia, and that no project he led had failed, thanks to the wonders of change/risk management - what seems to come down to explaining delays and re-evaluating the schedule based on new data.
Maybe consulting like this differs from other projects, but it seems like this is just failure wrapped up in a prettier name to avoid the stigma of having failed to deliver on time, on budget, or with full functionality. The fact that he explained that my company gave away hours of work for free in order to finish the project within the maxed out budget says a lot.
So I ask you this:
What is change management, and how does it apply to a project?
Where does "change management" end, and "project failure" begin?
#shog9:
I wasn't asking about a blame game with the consultants, especially since in this case I represent the consultants. I was looking for views on when a project should be considered "failed" regardless of if the needed functionality was finally implemented.
I'm looking for the difference between "this is actually a little more complex than we thought, and it's going to be another week" which I'd expect is somewhat typical, and "project failure" - however you want to define failure. Is there even a difference? Does this minor level of schedule slippage constitute statistical "project failure?"
I think, most of the time, we developers forget this we all do is, after all, about bussiness.
From that point of view a project is not a failure while the client is willing to pay for it. It all depends on the client, some clients have more patience and understand better the risks of software development, other just won't pay if there's a substantial delay.
Anyway, about your question. Whenever you evolve a project there are risks involved, maybe you schedule the end of the project in a certain date but it will take like six month longer than you expected. In that case you have to balance what you have already spent and what you have to gain against the risks you're taking. There's actually an entire science called "decision making" that studies it at software level, so your boss is not wrong at all.
Let's look at some questions, Is the client willing to wait for the project? Is he willing to assume certain overcosts? Even if he doesn't, Is worth completing the project assuming the extra costs instead of throwing away all the already done work? Can the company assume what's already lost?
The real answer to your problem lies behind that questions. You can't establish a point and say, here, if the project isn't done by this time then it's a failure. As for your specific situation, who knows? Your boss has probably more information that you have so your work is to tell him how is the project going, how much it will take and how much it will cost (in terms hours/man if you wish)
Unless the goals were clearly stated in the beginning of the project, there are no clear lines between "success" and "failure." Often, a project would have varying degree of success/failure.
For some, just getting some concepts in code would be a success, while other may measure success as recovering all investments and making profit.
Two well-known modes of failures are schedule slip and quality deterioration, but in real-world, people do not seem to care much about them.
Simple ways to slip the schedule are to let the managers make request whenever they want (features creep) and let the programmers code whatever they feel is right (cowboy coding). Change management process such as sprint planning of scrum and planning game of XP are some of the examples. Theses are some of the attempts for the management and the developers to ship reliable products on time. If either party is not interested in reliable or on-time, then change management would not be useful.
I suppose how successful the project is depends on who the client is. If the client were the company directors and they are happy, then the project was successful regardless of the failures along the way.
Andy Rutledge has written a pretty interesting article on success. Though the title is Pre-bid Discussions, the article defines having a successful project, which for Andy entails:
Will I or my team be allowed to bring our best work to the final result?
Is the client prepared to engage in the project appropriately?
Is the client prepared to begin this project?
Is the client prepared to invest trust in my or my team’s ideas?
Am I or is my team prepared to fulfill or exceed the project requirements?
This article was pointed out by Obie Fernandez, a successful consultant, in his Do the Hustle conference about consulting.
What is change management, and how does it apply to a project?
Change management is about approving and communicating changes to a project before they happen. If someone on your project (user, sponsor, team member.. whoever) wants to add a feature, the change needs to be documented and analysed for the effect. Any resulting changes to scope, budget and schedule must then be approved before the change is undertaken. These changes are typically approved by your sponsor, your steering committee or your client.
Once the changes have been approved and accepted that is your new plan. It doesn't matter what the original budget or schedule was.
Change Management on projects is all about the principle of "No Surprises". The right people (your Change Control Board) need to approve any changes to Scope, Schedule and Budget before they are acted upon.
One thing to remember is that there may be certain explicit or implicit constraints and tolerances for change. You may be have to deliver your project by a certain date to meet government regulatory requirements. Or your organisation may have a threshold that once a project budget is 30% over the original budget it must go to a "C" level or the project is killed. Investigating and explicitly stating these thresholds and tolerances up front are a good way of having better successful projects.
Where does "change management" end, and "project failure" begin?
If a project delivers on the approved scope, schedule and budget then it is successful.
However it may be still viewed as a failure. Post Implementation Reviews are a good tool to qualify this with your stakeholders (not just your boss). Also Benefit Realisation would be worthwhile looking into to see outside the blackbox of the project and the impact on the business as a whole.
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 does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
Skunk Works Project: A project carried out by one part of a company without the knowledge of the remainder of the company.
Looking for stories about any skunk works projects you've worked on or initiated:
Was it successful?
Were you found out?
Were you punished or rewarded?
How did you fund it?
How did you staff it?
How long did it take to finish, compared to above-ground projects?
What was the cost, compared to above-ground projects?
Was it formally adopted?
Excellent question. Very important question.
Geoffrey Moore (Inside the Tornado, Crossing the Chasm, etc.) has written that, as he lectured around the world, he had one question he would ask every client (including those like GE, Motorola, etc.)
The question was:
"Can you give me even one example of a truly ground-breaking, paradigm shifting innovation that has ever come out of your company's research or product development process?"
At least at the point where I read the quote, not one example had been identified. And in most cases, such products or services had been conceived, designed, and largely developed by small groups of people who at best were ignored, but were often actively opposed by R&D.
Not sure if this qualifies as a "skunk works" project, but here's a great story from This American Life. It's Act Two of this March 2005 episode.
Amy O'Leary tells the story of a
software writer at Apple Computer
whose job contract ends, but he
refuses to go away. He continues to
show up at work every day, sneaking in
the front door, hiding out in empty
offices, and putting in long hours on
a project the company cancelled. There
were no meetings, no office politics,
no managers interfering with his work.
Soon, he had written a perfect piece
of software. His final problem is
figuring out how to secretly install
it in Apple's new computers without
anyone noticing. (12 minutes)
Great listening for anyone, but especially programmers in this case.
I have actually done a number of these "Secret" project type situations. Were they are not fully supported when started, and kept very secret. I'll discuss on of these along the lines of your questions.
Was it successful?
Yes, the system developed was put into place 3 years ago, and has been functioning ever since.
Were you found out?
Yes, it was discovered, and it was part of the overall plan.
Were you punished or rewarded?
With a working prototype we were rewarded, given the extra resources needed, and eventually the system was put into place for the entire company to use.
How did you fund it?
It was a development activity that was simply completed in down-time and personal time by various people.
How did you staff it?
See the above.
How long did it take to finish, compared to above-ground projects?
We did the entire thing in about 4 months, with dedicated resources a single person could have done it in about 2 months, or a team in about 3-4 weeks.
What was the cost compared to above-ground projects?
No cost, using down-time that was already "wasted" to be put to effective use. All existing infrastructure for the final incarnation was already there.
Was it formally adopted?
Yes, it is a solid part of the business plan now, and has been for over 3 years.
We are currently in this situation, although, admittedly, the project will not have high visibility aspects - even though everyone will be eventually using it.
As part of a preparation to rebuild most of our enterprise applications, we have started developing an application framework that will be the basis for all of the replacement applications. We already have "bench projects" and "proof of concept" time that everyone is aware that we use to evaluate concepts. How it is different this time, though, is that we are actively developing a full project.
Was it successful? - We have not rolled out the full framework yet, but since it is modular, have been rolling out pieces in the legacy applications. Most of these are focused on stability and reporting/logging concerns. So far, they have exceeded expectations, allowing us to react to issues more rapidly, as well as eliminating some previously recurring ones.
Were you found out? - Well, this project has become one of the worst kept secrets I have ever seen. While there are quite a few people who have heard the name of the project thrown around a bit, I don't think anyone outside of a few of my developers and the testing team really know what it is about.
Were you punished or rewarded? - We haven't considered either side of this, yet. Unless the framework would cause negative effects, I doubt we would be punished for it. However, even if it is a success, the reward will be that no one notices anything other than improved applications.
How did you fund it? - Like mentioned before, bench time between other projects and inclusion in "proof of concept" work. I have also been putting some of my own personal time into it on my commute, since it will lay the groundwork for how all of my developers interact with the applications in the future.
How did you staff it? - I started with a series of small proof of concepts within the legacy codebase as part of "maintaining" the applications. Going in and fixing a defect often involved analytical steps on what could be done to prevent things from happening or improve the experience in the future. These were eventually extracted and refactored in their own assemblies, which became the beginning of the framework. We are now placing "covert" projects into our iterations that help flesh out these ideas through my developers, and we are now extracting and refactoring their efforts based upon the success of the implementation.
How long did it take to finish, compared to above-ground projects? - Yet to be determined. Since this is not an official project, so far it has really cost nothing. Bench time and "proof of concept" work is standard inclusion. The fact that we are essentially creating something from this time instead of throwing it away is gravy.
What was the cost, compared to above-ground projects? - Once again, yet to be determined. I imagine that the up-front cost will be relatively small compared to larger projects. Considering that this is a framework to contain commonly used extensions and improve the ability and quality of the developer to work efficiently, it will probably pay for itself before it is finished due to time-saving, improved practices, and reduction in defects.
Was it formally adopted? - The developers have embraced the concept. My immediate management is chomping at the bit. My management peers are excited, if not a little confused on what it will do. The measurement will be the success of the applications that are built off of the framework - which is some ways away still.
I built a tool to validate schema changes to the target DB at work. prior to my tool we did it all by hand with fugly scripts that DBA's at client sites had to run. my tool started tracking the structure of the database to know if certain things would work out. I got frustrated with having to hand check all this stuff or suffer from the errors inevtiable in doing things by hand so I built my validator and here is its story...
Was it successful?
Yes
Were you found out?
yes. Part of the aspect of a skunk works project is that it has to surface eventually.
Were you punished or rewarded?
Punished initially - why not work on mainstream activities. But rewarded once the benefit was made evident and product errors were reduced. Then it was heralded- everyone loves a winner.
How did you fund it?
For the love of coding it up and making my life easier - so no direct funds needed. Unless was part of managements plan to have a secret project i cannot see how this would be otherwise.
How did you staff it?
I coded alone as a lone developer on a grassy knoll with my laptop.
How long did it take to finish, compared to above-ground projects?
Not comparable. my skunksworks effort was maybe a year of tinkering. If we had set out to do it directly i cant imagine it would have taken less than 2 months directly but I do not know since thats not how it morphed. Downtime to think and plan may have made it faster in the end compared direct planning upfront.
What was the cost, compared to above-ground projects?
Undetermined - As I mentioned, given that I had down time to think and plan it was able to evovle in the direction I wanted without schedule/result pressures. In a shorter or more resource involved project we probably would have made some mistakes in rushin to get to some M1, M2 etc. Besides if it didnt work out, its would have been as if it had never happened as I could have folded up the tents and gone quietly into the night.
Was it formally adopted?
My project is a key part of the product build at my work so I would say its entrenched.
Hmm... I did one of these today actually.
We've got no real backup system in place. At present I get the highly enjoyable task of backing up 100GB of SVN repositories using svn hotcopy and .tar.gz files, while trying to juggle them across two or three NFS shares with limited disk space to get to the server with the backup disk. That's in the best case - i.e. when I can be bothered to babysit the process for 2 hours.
Since that's bound to end in catastrophe sooner or later I did a git svn clone on the largest one straight onto the backup server, then cloned that to my own machine and kicked out the svn working copy I was using. I've gained about 1GB of free space on my machine, given the most important backups some redundancy, and reduced a 15 minute svn st to a 30 second git status. And will I get complained at for it? Probably...
Generally the answers here have been success stories, so I thought I'd share my recent experience sitting just outside such a project that did not go so well.
How did you fund it?
How did you staff it?
The project started when my manager identified a potential employee, lets call him Fred, who had a pet project in our field. We don't pay well, and they they agreed that Fred would be hired and would work almost full time on the project, which they would eventually introduce to the business.
So Fred's started work on the project, known only to Fred's team but not to management or other parts of the business. Fred is a developer, and the work was more-or-less pure development, plus contributions to an underlying open-source project.
Was it successful?
Not really. Fred was working on it alone, and I think would have spent 12-18 months on it. Progress reports to the team consisted of describing whatever bug he was fixing that week. Occasional attempts were made to interest one or two higher-ups in the organization, but they never really went anywhere. Fred was supposed to put together a plan to finish and roll out the project so it could be introduced to the organization, but there always seemed to be some reason it was never done.
Were you found out?
Word slowly filtered out as Fred an the manager tried to interest more people in what they were doing.
Eventually we got restructured, and our new director wanted to know what everyone was working on, and the project was revealed to him. However, it was apparently not explained very well, since the new director wound up asking me (and others in our team I am sure) what exactly Fred's project was?
Were you punished or rewarded?
Eventually the new director froze all funding for the project and Fred was reassigned to work on other projects. That's the current status as far as I know.
How long did it take to finish, compared to above-ground projects?
Was it formally adopted?
It was not finished and it was not adopted.
What was the cost, compared to above-ground projects?
The ostensible cost was Fred's time.
However, there were other costs.
First, Fred and his project became a it of a joke in our team, and later in the teams we work with. What was he doing? Why was he doing it? Why was there no progress? Fred's reputation suffered. "Fred's project" became an in-joke for a project that was going nowhere.
Second, the eventual revelation of such a long-running but hidden project reflected poorly on our manager, and by extension on our whole team.
Third, resentment grew. Why was this guy working on his pet project when there was so much real work to be done? We are a small but busy team and we could have used a developer on any number of other projects.
In the end, I think this project has had consequences for our team's standing and dynamic. I occasionally talk it over with team members, when we're away from the office. Initially (and at the time) we were very critical of Fred, who can be an irritating guy, and who does not take criticism well, and who promised something he couldn't deliver. More recently, we've been critical of our boss. This was not a good way to run a project, and it was obvious from very early on that Fred did not have the skillset to do this work on his own and he would not seek or take advice. It was unfair to Fred that he was put in that position and left in it for so long. Lately I have wondered if I should have raised my concerns more forcefully. Though we did push Fred and our manager on what the project was and where it was going, we did not take it any further than our team. Having said that, I cannot imagine a good outcome even if we had.
Finally, I'd like to say that Fred is a smart guy and the project was not a bad one. It could have been successful (some parts have since come out in competing projects -- inferior competitors that actually delivered).
If this project had been done above board, and Fred had been working with a decent project manager and had a good communicator on the team, it could well have found a champion and delivered something great. Either that or it could have been killed a lot sooner.
I did one of these. It's actually how I ended up programming.
I was responsible for maintaining a legacy, er... "database". I won't go into gory details but it was the usual evil application. The company pretty much ran on it, it would sometimes go down for days. At the time the IS director (a friend) was actively looking for replacements, talking to large consulting organizations, etc.etc. but management was committted/emotionally invested in the existing system. I volunteered (to the IS director) to try to rewrite is (well, more like he asked if anyone was interested in trying to deal with this mess and I volunteered because I was bored). We had no real programmers on staff, and I'd only written a few small ad-hoc things. I had no idea how little I knew.
Finished the thing in about 8 months or maybe a year (this was a while ago, don't remember exactly).
Was it successful?
yes, worked as advertised.
Were you found out?
It initially started as a sort of super-secret, cloak and dagger thing. Kind of silly in retrospect, but it made it more fun. About halfway through it just started to become more obvious that that was what I was doing, and as it turned out the idea was supported. Writing this thing eventually became my job.
Were you punished or rewarded?
Rewarded
How did you fund it? / How did you staff it?
The success of it was pretty much due to the support of my boss, who made sure I had the time and resources I needed to do it.
Was it formally adopted?
Yes, we eventually ran the company on it.
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 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
I'm the leader of a small web development team, and I have a feeling that we will have a couple telecommuters joining the team pretty soon (either new employees, or existing employees that will begin telecommuting). Any idea how to effectively manage and collaborate with developers working remotely?
Most of the work we do is client-driven. We're doing agile development (or our version of it, anyway), but since it's mostly client work, we can't really assign a feature to a developer and set them lose for a week or two like we might be able to with a desktop app or something like that. The biggest problem we have when people occasionally work from home is collaborating - it's tough to work together without the benefit of a whiteboard and hand-waving.
It seems like software development is perfect for telecommuting, but I haven't been able to find many good resources about the practical aspects of working remotely within a development team. Has anyone else had any experience with this?
I freelance a lot and in doing so work remotely a lot of the time. These are the things that make my life as easy as possible (so might be things you want to "suggest"). I think they're mostly common-sense, but you never know...
[Everyone] Communicate well. When you're having a conversation face-to-face, you can be verbose and explain things in a round-a-bout way. When you're limited to email, IM and phone, all parties need to explain themselves fully but succinctly. I find that summarising long emails into request/action points goes a long way towards getting things done well.
[Everyone] Have a online project tracking space. Most tend to use a ticket system or some description, where action points can be assigned to members. It wouldn't hurt to use this same space for tracking emails and sharing whiteboard ideas. Most online project apps allow for that by default.
[Management] Don't pester devs. If you need something urgently, set the status of the ticket, give them a call and chase them up later on in the day. Half-hourly emails asking "is it done yet?" does more harm than good!
[Management] Make sure messages get passed along. If a dev says "somebody needs to do something", it's your job to make sure the message is passed along to the right person. There are few things more annoying than passing a message to a project manager for them to accidentally sit on it. I don't want to have to chase up things like that because it's, frankly, not what I'm being paid for.
[Management] Make sure people have something to do. If you send them home with nothing on their task list that they can immediately action, they're not going to put in the effort. It's a damned sight harder to keep yourself productive at home than it is in the office when you've little or nothing that you can do. You might have to juggle tasks if there's a blocker.
I work at home full time. Here are things that help in my small (6 people) team.
Set up rules for using IM. For example, allow remote workers to block off time not to be interrupted by email or IM. Require workers to keep status up-to-date somewhere (IM, Yammer, etc) which helps keep them accountable to stay on task. Stay in touch without being a distraction.
Meet in person occasionally if possible. Nothing can replace a face-to-face meeting. Skype is ok for group meetings, but not if whiteboards are involved.
Use SharedView or another screen sharing program for collaborating. Screenshots/screen captures are helpful as well to make sure both parties are on the same page.
"Any idea how to effectively manage and collaborate with developers working remotely?"
What does "effectively" mean? I can be negative and assume it means "with me, the project leader in control of everything". I can be positive and assume you want people to be as effective as possible.
Sometimes, "effective" is management-speak for "under my control". Or it means "not screwing around."
The question, then is "effectively doing what?" Effectively "working" is rather vague. Hence my leap to the dark side of project management. [Which, I admit, is probably wrong. But without specific team productivity problems, the question has no answer.]
"it's tough to work together without the benefit of a whiteboard and hand-waving" This is only sometimes true, there are lots of replacements. The "hand-waving" over the internet happens more slowly and more thoroughly.
The group-think around the whiteboard is fun -- it's a kind of party. However, for some of us, it's not very productive. I need hours to digest and consider and work out alternatives; I'm actually not effective in the group whiteboard environment.
I find it more effective to use the alternative "slow-motion" whiteboard technologies. I like to see a draft pitch for an idea. Comment on it. Refine it. A lot like a Wiki or Stackoverflow. I really like the internet RFC model -- here's my idea; comment on it. When there are no more improvements, that's as good as it's going to get.
I work in Mississippi and my home office is in Michigan. I spend several hours a day pair programming with my team with ease. The tools I use are:
SharedView
Remote Deskop Assistance
Live Meeting
Oovoo
Skype
Depending on who and how many will depend on the tool I use.
"Use the right tool for the job and invest in a damn good headset." - Me.
I've generally used some time of community based software such as a wiki, blog, or forum to handle the documentation areas. We also have a Cisco phone system and use some capabilities of the system. I'd also recommend live meeting or webex to do frequent team meetings. Skype and IM clients such as Live Messenger are also good tools. For the short status updates, twitter does the trick.
Check out the Agile Scrum methodology with VSTS. Scrum forces us to have daily 15 minutes meeting and small mile stones , It makes sure the effective togetherness and tight communication. Make sure you use Task,Bug assignment etc through VSTS
I agree with John Sheehan's response. I am a consultant and manage other consultants - both on a project basis (as PM) and on a client basis across projects. I have worked with developers on a purely remote basis as well as telecommuting (meaning the majority of time we are co-located). Working remotely is a matter of trust and communication. Co-locating is best, but if you work remotely, simply create a culture of frequent communication. IM and phone are great for this, email less so. If you have a less than communicative co-worker, it is up to you as the manager to reach out. Ask for status. Force code-checkin on a frequent basis for review.
[EDIT] - Yes, don't pester and set expectations! Be clear and concise.
First of all use scrum (daily scrum calls, scrum board w/ burndown chart (wikis do a great job there), iteration in sprints etc). Next to that use tools that make it more easy to collaborate remotely like skype and VNC (maybe campfire?) and a wiki. I worked for 2 years on a project w/ people in 3 countries on 2 continents and various time zones and it worked quite well. The key is having tools and methodologies that make it more difficult for people to "hide", so that everything you and your team does is visible.
I find clear communication and staying on task are challenging with virtual teams. I try to use regular scheduled update meetings (over the phone or video conference) with a written agenda to help with these challenges.
At the front on the agenda list the major milestones and the near term milestones. The first item is always "check progress" each team member simply updates us on when they expect to finish the particular tasks involved. We try not to get involved in long stories here. It's simply "what are you going to do and when".
Once the progress check is done deal with any other issues raised in during the last week and any issues the team has that can be sorted out whilst you are in the meeting. Anything let over (such as new issues raised) needs to have the question asked "who is needs to sort this out and when".
Once you set a common format for the meeting you can do this weekly in 30-45 minutes with teams of 5-8 people. Keep it short and sweet so it isn't viewed as an imposition. Keep it focused on actions and schedule so it can be valuable.
I'm currently the PM of a smaller project that has two developers (myself and another developer that works out of the office). We are currently having daily SCRUM meetings, which last for about 15 minutes. We discuss what got done the previous day, what problems were encountered and what I can do to help with these problems, and what will be done tomorrow.
They're pretty quick and seemed to be very helpful.
Using a Time Tracking Software for your remote employees can greatly help you in managing the team.
While hiring a remote employee, you would be concerned about,
The amount of time spent in getting a task done.
The quality of the work done.
Collaboration based on the progress of the project.
The real time progress on a task.
Collaborating to solve bugs and logical errors.
I was in your situation a while ago and then I tried StaffTimerApp and it helped me in the following ways.
A Time Tracking Software gives crystal clear statistics about the time spent on getting a task done. StaffTimerApp captures screenshots and converts them into billable and non-billable hours. Hence, you would know if any time was wasted while getting the work done. You would also know the exact amount of time spent in getting the work done. If you pay your contractor by the hour, this application can help you tremendously.
If you use a time tracking software that captures screenshots, you can look at them to analyse the quality of work that is being delivered. I used this feature and was able to save some tasks from derailing.
A Time Tracking Software lets the employer know how far along the employee is with the task, hence the information extracted by Time Tracking will make collaboration easier. StaffTimerApp proved to be very helpful as I was able to collaborate with the other employees based on this information.
The screen sharing feature equipped me with the power of viewing my employee's laptop screen in real time. This way I would get to know about the progress on a task.
So you need a good Time Tracking Software with great productivity analytics and employee monitoring capabilities to feel comfortable with hiring a remote developer.
My dad always says "Responsibility without Authority is meaningless".
However, I find that as developers, we get stuck in situations all the time where we are:
Responsible for ensuring the software is "bug free", but don't have the authority to implement a bug tracking system
Responsible for hitting project deadlines, but can't influence requirements, quality, or team resources (the three parts of project management)
etc.
Of course there are tons of things you could say to get around this - find a new job, fight with boss, etc....
But what about a technical solution to this problem? That is, what kind of coding things can you do on your own without having to convince a team to correct some of these issues - or what kind of tools can you use to demonstrate why untracked bugs are hurting you, that deadlines are being missed because of quality problems, and how can you use these tools to gain more "authority" without having to be the boss?
***An example - the boss comes to you and says "Why are there so many bugs!!?!?" - most of us would say "We don't have a good system to track them!", but this is usually seen as an excuse in my experience. So what if you could point to some report (managers love reports) and say "See, this is why"?
All you can do is your best, don't feel as if the key to successful software is only in your hands, your part of a team and don't have to be responsible for all.
Obviously you are in a environment that affects negatively your software, but can't change all his behavior so I recommend you start with yours, start working as a team of one with your own bugs, deadlines, requirements, quality and resources don't bother for the rest of the mess, but try to be the best at your work.
Working as a self-directed team of one showing your boss your plans, and reports of your progress, asking for more resources when you need it and showing him how your plans get affected when he give them to you or not.
You can find more advise about this in the PSP and TSP articles of wikipedia
After showing your boss a good work and meeting your own deadlines, surely he will trust you more and let some of your ideas flow to the entire team.
You don't need a bug-tracking system, you need automated tests: unit tests or otherwise. You can set-up automated tests with a Makefile. You can always find paths that are blocked by management, but that doesn't mean there aren't things you can do within the constraints of your job. Of course, the answer could be "find another job". If you can't find another job now, learn some skills so that you can.
The simple answer is -- you can start using the tools yourself.
Improve your own work. If people want you to fix code, tell them to file a bug. Show them how. Make sure they can do it without installing anything. They want a status update? Tell them to check the bug. They ask abou a code change you made? show them how to make a source control history query. or just show them on your box. Start showing them this stuff works.
And when you need the same results from them, demand that they do the legwork. When you can't find the changes in your source control, ask them to start diffing their revisions manually from the backup tapes. Don't do their work, or the work of source control and bug tracking, for them.
And most importantly, when applying this peer pressure, be nice about it. Flies and honey and all.
If they don't get it, you can continue to be the only professional developer in your company or group. Or at least it will help pad your resume: 'experience setting up and instructing others in CVS and FogBugs to improve product quality' and the like.
As for specific tools for showing that untracked bugs are hurting the team's ability to produce quality code, you've got a catch-22 here since you need something to track bugs before you can show their effect. You can't measure what you can't track. So what to do?
As an analogous example, we recently had a guy join our team who felt the way we did code reviews via email was preposterous. So, he found an open source tool, installed it on his box, got a few of our open-minded team members to try it out for a while, then demoed it to our team-lead. Within a few weeks he had the opportunity to demo it to all our teams. The new guy was influencing the whole company. I've heard lots of stories of this guerrilla-style tool adoption.
The trick is identifying who has the authority to make the decision, finding out what they value, and gathering enough evidence that what you want to implement will give them what they value.
For a broader look at how to lead from the middle, or bottom, of an organization, check out John Maxwell's The 360 Degree Leader.
If you want a report about quality and it's impact on productivity - here's the best:
http://itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html
Caper Jones has a few books out and is still showing up at conferences. Outside of a good IDE a developer/IT group needs source code control (VSS, SubVersion, etc ) and issue tracking
If an accountant is asked to produce a set of account without using double entry and don’t balance, no one would expect the accountant to do so.
However double entry has been in standard usage by accountants since about the 13th century.
It will take a long time before we as a profession have standard practise that are so ingrained that on-one will work without them.
So, sorry I expect we will have to face this type of problem for many year to come.
Sorry for not answering your question directly, but...
I feel strongly that the failure you refer to is one of communication, and it's incumbent on us as professionals to develop our communication skills to the point where we are respected enough and trusted enough to leverage the authority we need to improve our working environments and processes the way you suggest.
In short, I don't think there is a technical solution that can solve all the problems created through poor communication in the workplace.
If anything, technology has caused the attrition of direct face-to-face communication.
Sorry, I'm off on a tangent again - feel free to downmod.
Coding only you can only keep your own source files tidy, well commented, keep the bug count low with tests. But you are going to need external tools for tracking progress and bugs (bugzilla, yoxel, trac, gantt diagram tools, Mylyn for Eclipse, a blog, whatever). In these cases the people and the discipline and the good habits and the leadership are the overwhelming force, no software tools and no offert from the individual can win alone.