So, there you are – looking at vendor proposals for an outsourced, software development project. You will review the project outline or plan, consider the technologies proposed, the timeline, the methodologies, and… the resources offered. Resources will lineup two ways – their role and their resumes, which will include their skills and experience. The resumes can tell you a lot, but the roles can tell you even more about how the vendor plans to organize the project and the responsibilities of the team. Are they going to work as an agile team? Are the using scrum or another method of organizing teamwork and tasks? How much responsibility are they placing in the team and how much do they depend on hierarchical management structures?
Of course, as you look at those proposals, you will view them through your own experience. Do you have experience with small, agile teams or are you more of an enterprise-level, project portfolio person? Do you understand and feel comfortable with the plan and roles you have been offered? Is risk handled in a way that makes sense for the project? This is where the “rubber meets the road.” Do you feel comfortable with the way the vendor is proposing to organize your project?
If You are an Agilista…
In the agile world, one of the basic tenets is that teams should be self-organizing and that individuals need to take responsibility for the tasks they accept and to operate as a sharing, collaborative member of their team. At that level, agile would seem to say, an extra person with the title of Project Manager is just overhead and is likely to slow things down by creating an unnecessary layer of management overhead. If your vendor proposed an agile team with a project manager, you might raise the question, “What is going on here? Are your team members not properly trained? Are they new, junior resources? Why are you adding layers between the team and the product owner?”
If You are a Dyed-in-the-Wool, Enterprise PM…
You have been trained to understand team management, the benefits of detailed planning, and the discipline of Project Management. The idea that teams can see the “big picture,” deal with the threats that come to projects as they navigate toward success, all the while being productive software developers in a project is an anathema. It just doesn’t work that way. The PM is the wall between the team and the problems that rise out of nowhere to derail projects and when they do hit, put things back on track toward the goal. If your vendor proposed an agile team without a project manager, you might ask, “Do you expect team members to establish proper timelines for deliverables, integration, release and manage them through likely issues over the entire project lifecycle? Can team members navigate the client team to find the subject matter experts they need and prioritize work while they do it? Can team members evaluate the risk they bring in if they change their technical approach or reprioritize their remaining work?”
What is Right? Neither? Both? Vendor-Side PM or No?
Let’s say up front, the majority of software development teams today are agile, aspire to be, or claim to be (whether an objective analysis would approve of their practices as agile or not). So, that said – it isn’t hard to find that the general agile point of view is that the role of project manager is unnecessary at best and counter productive in many cases. The suggestion is for project managers to become scrum masters or product owners, with the caveat that their training and inclinations won’t help them much in either role.
But, of course, there is another camp. The advocates of “agile PM” have another point of view. They ask: Is a scrum master going to organize the vendor bid response, initiate the work to be done in Sprint 0, set logical team goals, find the critical path for a project, deal with issues and external risks, and insure team cohesion and communication with outside entities? They assume the team will not recognize these issues and if they do, will not feel enabled or be given the opportunity to deal with them. They may have a point, especially if a team has a majority of junior resources.
To take this discussion down the road a little further, many teams assume that the scrum master role is just part time. In their world, the scrum master manages the ceremonies of scrum, but is not necessarily concerned about larger project issues. Those issues may be taken on by the team as a collaborative unit, or they may be assumed to be the domain of the development manager. In these cases, the scrum master will probably be a senior developer, and they will take responsibility for development tasks along with their scrum master role.
Notice that the table above mentions “small development environments.” In most cases, that refers to agile teams of not larger than six or seven individuals and in most cases will be teams of four or five. Larger teams, or teams within teams as we find in a scrum of scrums used in larger projects, require a different approach and may be fertile ground for an agile project manager. It is also true that most vendors with multiple teams working on different projects and clients will also have an agile project management office (agile PMO) that takes the role of not only assuring standard practices and processes are used across the board, but will also take on the role of ensuring gaps don’t occur that could endanger a project without setting up a formal project manager for every project.
So, Who is Right?
Of course, in the end, the right answer is – it depends. Some outsourcing vendors have a business model/marketing message that says they deliver their projects with the lowest cost resources. They base their approach on a target average hourly labor cost that will be comparable to other companies operating with the same idea. This often means the resources will be junior and will not be expected or enabled to take decision-level responsibilities or communicate directly with product owners/client subject matter experts. In those cases, you will often find senior resources acting as project managers, technical advisors with high hourly allocations, or vendor-side product owners who intercede for the team in documentation and data gathering tasks. This isn’t to say these practices are bad, they are a recognition of the reality that low-cost resources do contribute to project overhead and they do impact the Total Cost of Engagement (TCE) for the project.
In a perfect world, outsourced agile teams would have the guidance and experience to deal with project management level issues themselves. When they can’t, they would have a development manager and/or an agile PMO to help them recognize issues and deal with them proactively. Creating extra layers of project managers or management interfaces that intercede for the team and in essence, keep them out of the communication loop, lower or eliminate the value of agile as a development methodology.
But, we don’t live in a perfect world. Larger projects, teams within teams with their own deliverables, integration with enterprise-level organizations, may create situations that are better handled by a project manager, instead of burdening the development team with problems outside of their production role. In the best case, if you have questions about project organization and the need for proposed vendor-side roles, it should become an opportunity for discussion and a better understanding of the whys behind the proposal. Assumptions lead to misunderstandings and software development projects that start off with misunderstandings are destined to have problems.
At Scio, we have experience providing nearshore teams for many types of outsourced projects for a a range of client organizations from startups to Fortune 100 enterprise. We will work with you to structure a team that fits the needs of the work and goals at hand, rather than assume “one size fits all.” Our teams are skilled agile practitioners and can adapt successfully to many different situations. If you have a project in mind and would like to explore our services, we would be happy to discuss your needs.