Professional Services is clearly not my area of expertise (I have not been a contract-based service provider first hand) but I enjoy participating in the #ProfServ Twitter Chat led by @KRCraft @Berkson0 and @fredmcclimans (bi-weekly, next Dec 23rd 10PM EST).
In the last chat a week ago, I was hearing about the challenges contractors and service providers face in defining and managing scope and billing customers. Service Providers need to limit the amount of “free consulting” and then be careful defining the acceptance criteria of the project. Customers worry about escalating hours/costs and false “success” that does not deliver the business benefits. That difference in perspective also manifests in the conflict between Time&Materials or Fixed price models.
It is not too difficult to see that the issue is the same software companies face internally: The engineering department provides service, the product marketing department is the internal “customer”. Engineering never knows how much time a project requires and Marketing never knows the true market requirements in advance. Yet both pretend they know everything, sign up for very detailed and structured 12-month product development plans. And fail miserably.
The Agile software development process emerged in its current form as incremental software development methods as the pendulum moved from the ad-hoc methods of the 70’s and 80’s to the extreme ISO9000-like planning of the 90’s and back. The Agile Manifesto came out in 2001.
I was sure it was not a new idea, but I thought: “Does it make sense to think about Agile Professional Services?”
After some time in Google, I am surprised that, though it is indeed not a new idea, it is under-explored. I haven’t been able to find good articles or material exploring the extension of Agile processes outside an organization.
My bullet-level description of an agile process (not necessarily the “A”gile Process) is:
- People, interactions, working systems, embracing of constant change are more important than processes, tools, documentation, plans.
- Partnership and mutual trust are essential. Communicate constantly, and at least daily without exception. Easy to say, hard to practice.
- It is important to share a vision, the notion of success, and understand who the user is.
- Don’t pretend you know every step of where and how. Agree on the direction, establish short-term incremental goals. Slides, plans, ideas are not acceptable deliverables. You must get to something incremental but tangible and demonstrable.
- Execute, Evaluate, Adjust based on user feedback in quick iterations (in SW development, that means “Sprints” of 2-4 weeks).
- Jointly measure actual progress and use that to plan the next iteration.
- Rinse, Repeat.
I don’t really know how to translate it to the Professional Service world. Maybe, it would mean something like (a) establish trust and common vision, (b) run a sequence of incremental fixed-scope, fixed-price iterations grouped into a larger open scope that evolves as the project takes form.
Even in the software development area today, when a project is contracted to external organizations, we tend to gravitate towards fixed scope/price, traditional project management, not agile. The communication requirements of an agile process are difficult to implement with external parties.
So the question remains: Does Agile Professional Services make sense?