5 Commercial Considerations You Should Make Before Starting a Project with a Service Provider

30 July 2013

Luis Brea
Agitrend Inc.


Since being introduced to the Scrum framework, I have realized that many of the factors that I intuitively knew determined the success or failure of a project had been collected, defined, and analyzed under this method based on Agile. With some commercial considerations, the Scrum approach allows working with implementations done by external service providers (SP) for small businesses that lack both qualified and experienced resources to accomplish any systems customization or development but are in great need of applications and systems to help them control and manage their businesses.

Consequently, I would like to share some of these commercial considerations in project management using Scrum -- considerations that should be taken when working with an external SP:

  1. Do your best to find a SP that has a team of developers certified in Scrum, or that has experience with this framework at least. If it's not possible to find one, invest a day or two -- before starting the project -- in a Scrum introductory course for the team members (both internals and externals). Define the roles, ceremonies, and artifacts, clearly indicating the length of each sprint. The use of the Scrum framework should be agreed in writing in the statement of work (SOW) as a contractual bond, stating furthermore the frequency of meetings, all the team members, and the definitions of roles. The SOW should also be declared part of the service contract to be signed by both parties (client and SP-authorized representatives). If it's the first Scrum for any of the two parties involved, add a few hours of Scrum coaching with a qualified trainer along with the introductory course. This investment is much lower than facing the risks and costs associated with traditional project management under the Waterfall approach.
 
  1. Reduce internal bureaucracy. If the external development team of the SP does not have the support of the contracting company staff, times will lengthen inexorably. The work of the ScrumMaster is essential in this case to deal with the bureaucracy of the business, facilitating the work flow and information exchange, and solving problems and obstacles that arise unexpectedly throughout project implementation. The SM obviously must be a key person of the client, invested with authority and with excellent negotiating skills. I recommend you choose a key employee from the commercial or financial departments.
 
  1. Reduce excessive development hours that may increase the overall project cost. Excluding standard deployments that don't require major customizations to their implementation (in most cases the cost of development, implementation, and/or integration of new systems) outweighs the costs of licenses, software products, and hardware required to run the project. Anticipate that the SOW is signed with the outsourcer based on functional deliverables instead of professional service hours exclusively, as usually happens. Estimate along with the service provider the amount of time (set a maximum number of hours) per functional deliverable, which, if not achieved in practice, can be charged at a reduced rate until eventually being dismissed for service levels oriented to customer satisfaction. This means you will be setting service-level agreements (SLAs) for service deliverables. It is key to achieve partial deliverables that provide business value and that could be anticipated in the SOW as addendums for each iteration, whether or not priority has been set at that point in time. Addendums to the SOW will come from the backlog. The client shouldn't overpay for deviations that are not accountable, and the SP should seek customer satisfaction by leading to a faster ROI for the client. Current "time to market" does not allow long implementations, which may differ from getting "measurable" results to the business.
 
  1. Whenever the client hires external developers, make sure to have at least one client team member who has the technical knowledge required to interact with the SP but who also understands the business and the benefits that the new development or application will bring to the company. This person should obviously be appointed as the Scrum product owner (PO) for the project. Unlike a traditional PMO, the PO is actively involved in the implementation and will not be limited only to keeping track of progress, accounting records, and percentages executed. Projects that lack this human interface (PO) also tend to elongate and produce client-side frustrations.
 
  1. Leverage the use of video conferencing, Web chats, and online meetings to make the most out of your sprint planning meetings, daily planning, and sprint reviews. Developments contracted to external SP are usually performed remotely, i.e., off the customer's premises. It is also likely that most development team members are distributed across more than one geographical location. This should be no impediment for Scrum ceremonies. Daily interaction and fluent communication are key factors to avoid extending the project, mainly because many SPs run more than one project for more than one client at a time.
 
It is my belief that using Scrum in projects that involve service providers' assistance will result in improving accomplishments and ROI for the client, allowing clients to gain more control over projects handed over to SP compared to those run under traditional project management.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.5 (2 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.