A few things that you might want to consider:

1. Making sure that there is one person (you!) as a ‘gatekeeper’ for projects and priorities.

2. The hardest part of the shared unit is defining priority – that’s something that you’ll want to openly talk about not with the open group, but with management. Not every task is equal, and not every task is of equal priority to the organization. (i.e. if there is an issue of setting up an online sales portal versus a reporting system for HR – the sales portal would likely come first.)

3. Buy some quality fire-treated clothing. The seat might get hot from time to time. 🙂

Programmers are not coffee mugs!

Coffee mugs, furniture, laptops, and sometimes even labor can be shared between departments, units or team. And I bet, coffee mugs wont crib or fail. It’s just that sharing programmers, while good and possible is not that straight forward.

There is nothing wrong with regards to sharing. The trouble is not really about two different departments who are trying to share. The issues are usually with the programmers who face constant change.

Here is what you might want to consider:

1. The time slices and thrashing. –
   Just dividing number of hours (or even worse minutes) of time slices for the person to shift around the jobs makes the programmers exponentially unproductive as the overall slices go smaller. Specifically I would prefer to work on at least a week long switch, sometimes at least a few days at a time -but definitely it will limit

2. The familiarity and dependency.
   The familiarity of domain and problem and dependency on others is what make or breaks many software projects than the ingenious skills of programmers. You may give freedom to the programmer when will he work on the (do coding and testing) of second project- but when you need to meet other team members, attend meetings that does brain storming and decision making about requirements, project management, customer interaction – all this cann’t be really done in isolation and you might just get contesting between the meetings.

3. Scope & responsibility
   What is very important really is how do you want to borrow the programmer – do you just expect some guidance or consultation? or is he/she expected to write some independent code; or he/she going to participate in interactive process be it requirements, design or integration? Who is going to maintain

4. Last but most important –
   It may not always the case, but different teams have different ways of approaching to solutions, different types of coding; some team’s customers put high significance on timeline where as some will expect absolutely bug free software. Working on different project makes you adapt to some of this factor. However, when you are constantly switching between to different types of projects it takes a toll!

Having said that, it is always visible sometimes that optimizing projects by exchanging resources is important and quite often. But ultimately it boils down to the capacity and capability of the individuals who are shared.

The biggest problem I could see is that each business unit will believe that their project is the highest priority, and the others are unimportant.

You will probably already have some formal resource allocation plan. The key will be managing exceptions. What happens if a critical bug pops up on an application, and there aren’t any developers allocated to that application at the time. Or if it’s a junior developer.

What you don’t want is for your developer’s phones to be ringing all day with the various business units. You will need to establish clear lines of communication between the business units and the developers, and a defined process for how work gets done, and enforce discipline on the development team that they don’t drop everything and work on a feature just because someone stops by their cube with a problem. They need to follow the process.

Time allocation, scheduling, procedures, etc. is just administrative work. It’s a necessary evil. What is more important is the intent.

Usually, the productivity of developers is proportional to their expertise (of a particular project and technology). The more they stay focused on a project, the better they know it, the more efficient they become.

By pooling/sharing them among several, you loose this productivity. But there may be a reason to do so: transfer of knowledge. You sacrifice your own productivity to teach/help/assist others for them to become more familiar with a technology, hence more productive. This can have very good results as learning is a time consuming activity, and a mentor is very useful, especially for sparsely documented projects or technologies.

However, if they think like “the deadline is next week, let’s add N developers to it!” they are doomed. Indeed, developers are not interchangeable pieces. Even worse, adding developers at the end of a project may hinder it more than help, delaying it even further.

First of all, you need a unified delivery platform. Whether it’s a website or a single composite application. It’s one thing to manage functionality for multiple business units, it’s another thing altogether to manage multiple applications. By having a single platform, the opportunities for code re-use increase. Also it will allow you to align features from multiple business units.

Second, invest in Kanban training if you don’t have it yet. You’re going to receive a lot of feature requests that vary greatly in complexity, impact, and priority. Attempting to plan projects or Scrum Sprints that address these needs is a logistical nightmare. Instead focus on one thing: priority. Let the business decide the priority of the backlog and feed the pipe. When the team is ready for a new feature, take the next one from the top of the list. You’d also have to invest in a continuous delivery strategy so that you can deliver new functionality as it’s completed rather than having to do large deployments.

We have a kind of one-stop shop that supports a lot of different applications that belong to different parts of the business (and ultimately to clients).

First thing is to organize for success. Get everyone in the group on the same source control for instance. Next even though you all report to the same person rather than diffeernt business groups, there is nothing stopping you internally from designating programmers by product line or internal client.

We do move people around some in an emergency or when a new big project comes along, but generally they work on the same applications for the same clients. Each internal group of people may support multiple internal clients though. This at least gives the best chance that someone familar with the application is looking at it. It also means the C# programmers will be working with the C# programs and the Access programmers won’t be expected to suddenly take on a project way out of their skill set.

If you are bringing together groups with wildly different expertise, then you need to build a matrix of who is qualified to work on what. (This will help in resource planning). You may need to find the time to set up some cross training, so that developers who use languages that don’t have many projects can expand their skills to be more valuable to the group.

You may also need to look at making sure you have created a path for developers to move up in the organization. One of the few benefits to the change you are about to make is that more devlopers in one place means more chances to move up to senior developer and technical lead.

Given that you previously had many programmers in different parts of the organization, likely you have wildly different types of expertise, coding standards, processes. Some teams might be agile and some might be using Waterfall. If you want this to be effective in the long run, you need to work on moving to more standarized ways of doing business. Start with source control, then move to processes (If you can get everyone on agile, it might help some of your resourcing issues as once someone is on a sprint he or she woudl stay on the sprint.) In some teams you might have support devs and new development devs and others might expect a person to do both new development and support. Standardize on one method. Determine if possible a stardard set of tools you will all use or that will be used on all new projects. Set coding standards that will be used for all new projects (It may be too much to expect to change all the existing code done using a wild variety of standards.)

Next you need to set up how you are going to handle resourcing. There has to be a weekly or monthly resourcing meeting and all new projects will go into it and resources will be assigned. Resources can be reassigned between meetings but only within the resources available to a particular group (so if accounting has 3 resources assigned this month, they can move them from project A to project B when it suddenly becomes a hot topic, but they can’t steal resources from the Sales team until the next resource meeting). If you are doing agile, the resource planning meeting should be one week before the start of a sprint and all sprints should be on the same schedule and duration (everyone has two week sprints and the sprints all start on the same day, for instance). Do not forget to allow time for production support in resource planning.

Get a standard process set up for how you will estimate the hours needed for each project. Do not forget to add time for QA, fixing bugs, deployment issues, development of technical specs, communication (you can spend a lot of time in a project on meetings and emails). In your resourcing, never plan any person for more than 75% of the time (you have to allow time in the schedule for leave,holidays, required company meetings, unavoidable delay, setting up computers when they havea new one etc. ) In my experience assuming 100% of the time for project work is one of the biggest reasons for deadlines to be missed, no one is ever at 100% of the time on direct work forever.

Make the individual departments you are supporting responsible to create requirements documents. If unfamilar people will at times be working on their projects, you need formal requirements documents. No Requirement document, no project. Period. Also, you will have to have a formal project management system set up. No one will work on anything until the internal client has set up a project to charge the time against. No more “oh by the ways”, everything will have to be formally requested and worked into the resource plan. No more last minute requests either (except actual production bugs of course), let them know that all resources will be planned X amount of time in advance. Bugs should be reported in a formal system as well, there are many bug trackers out there.

In implementing the change, now might be a good time to get things you haven’t been able to get before, like better equipment for everyone or some tools you would like but haven’t had the budget to purchase (ask for suggestions from the folks in the trenches). Make sure everyone at least has two monitors!! And a good chair. Getting better euipment might help people in accepting the new system as at least there will be something in it for them!

I’m sure there is more, but that is all that comes to mind right this second. At least it will get you started on the planning process of how to implement.

First off, if managers of various non-technical departments are used to having someone with a coding background directly reporting to them, to whom they can hand off technical projects, and now all those technical people are in a department reporting to someone else, the managers are going to do whatever they can to get around the new “normal” processes and get to their former techie. They aren’t going to like this new arrangement one bit; they’ll perceive slower responses to their requests for new work, more hoops to jump through, and extra costs that used to be fixed at the techie’s salary (if techie time is “budgeted” among the rest of the departments).

You (in the shoes of the new manager of this new tech department) are going to have to nip this in the bud. First, you’re going to need to restrict access to the tech team, physically if necessary. This starts with the tech team themselves; they must understand that they now work for a new boss, who is going to evaluate performance based on what he told each techie to do, not what their old boss is trying to get done via an end run around the process. There will be a transition period as there is with any reorg; techies will have to “break up” with their old bosses (“I know, you were great, but we have to stop seeing each other like this”). People who remain stubbornly loyal to their old bosses may have to be let go; if they won’t do what you want, they’re useless to you regardless of their capabilities.

If the tech team is trying, but the old bosses are still wiggling their way past whatever gateway you set up, then make that gateway physical; have maintenance install a keycard door leading to the developer offices, and only you and the devs have access. When their old bosses come to you angry about this, stand your ground; they work for you now, not them.

As for scheduling the techies’ time on projects for other departments, that’s a business decision that is dependent on the number and scope of these projects. Usually, if the old scenario was a bunch of individual devs doing whatever the department needed, that usually means a lot of little stuff. Prioritize it and hand it to the devs best qualified to work on it. When it’s done, it’s done, and arrange delivery to the department that requested it.

Now, that strategy may seem to make you redundant; if all the techies are still doing the same work they would have done under their old bosses, then what’s changed? What’s changed is that now you can see the big picture based on what’s coming in, and guide development efforts along the way. You don’t have to have the techs do exactly what the department heads ask for, if you see a way to do it better. Look for opportunities to improve processes, and to consolidate piecemeal solutions into something more purpose-built. Obviously, coordinate with the various departments, but as the head of this new development department, you’re basically now in the de facto position of business analyst; if you see a better way to do what’s being asked for, by all means pipe up.

What’s also changed is that all these individual devs are now organized under a team structure, and what would have taken one dev weeks can take the team days. These “big projects” for business process automation and engineering are going to take a team effort; that’s why they didn’t get done before, because there wasn’t a team to do it (and there wasn’t someone with the willingness and/or authority to coordinate across the multiple departments on a single solution).

What is not clear from your question is WHY they are wanting to do this. If its simply to have a mangement structure that understands development processes, then the simplest way is to maintain the existing teams, just now inside the one department – and nothing much changes, except the line management structure. If the reason is to enable “more efficient” use of resources by having developers rapidly context switching between projects more easily, then I would be considering which developers are expendible, and who is essential to delivery. I would make sure that the majority of the rapid context switching is done by the developers that are the least useful. When they get fed up of not achieving anything they are likely to leave, and in the mean time, you have managed to keep the most effective developers productive despite higher managements best efforts of sabautage.