Our company is growing and the processes that support our e-commerce efforts must be ready to grow along with the business. Looking to ensure our abilities to effectively manage this growth, we recently decided to form a strategic partnership with another outfit that will develop, operate, and maintain our various e-commerce sites, as well as replace our internal sales and customer service applications. You could say our company's strength is in quickly executing our e-commerce, marketing, and merchandising initiatives. In other words, we are SaaS'ing our core competencies and processes.
All of our company's technology is totally home grown (except for the usage of Microsoft Commerce Server which our sites were built upon). Up to this point, our internal IT staff has developed, operated, and maintained all of our e-commerce sites. We've also created from scratch the entire suite of applications and tools that serve as the back end operations to our business.
Our partner arrived at our offices last week to officially "kick off" the relationship by discussing the first project we will work together on. The project manager began things by presenting their engagement model and how they run projects with each of their clients. The slide in his deck that helped describe their project process was a very nice looking diagram that appeared to be split up into various phases that included sequential steps, all flowing in a downhill manner, marching toward a completion date ~3 months into the future.
Wait a minute....
hold on here....is that...
yes...I think it is...
that appears to be a....
Their plan included a 3 month project schedule with a ~1 month "iteration" somewhere in the middle. This followed an exhaustive requirements and UI wireframe gathering period where we would sign off on the deliverables. After we waive our ability to change our mind sign off on the requirements, our partner would then go away (this is the iterative part, I guess?) and do the work. At the end of this period, the web site (that's the main deliverable that can be demonstrated) would be unveiled to us and at that point the initial requirements would be open for modification and all bugs will be worked on and fixed until the day the first site launches.
While this was being explained to us, our team (which included all the main business owners within my company as well as a few of us technical guys) immediately began asking about feedback, backlogs, demonstration of working software during the project, communication channels, etc. The responses to our inquiries** served to paint a very clear picture regarding just how Agile our group has been in delivering business value over the past year....and how non-Agile our partner seems to be. At that point, I think we all recognized how good we had it while working as an internal team, co-located and committed to a common purpose for a company we all worked for.
We ARE Agile
Our attempts at delivering working software internally over the past year have followed the Agile/Scrum process. We very much believe in and implement the tenants of the Agile Manifesto. We communicate. We adapt. We don't lock in our stakeholders to agreements, statements, or requests made weeks(months!) in the past. Key implementers don't go away and create solutions for weeks at a time with no customer interaction. We are open and available, not hidden away.We work at a predictable pace.Once we started holding daily stand-ups and displaying our sprint burndowns, our stakeholders became addicted to the constant feedback they receive on the progress of work being completed and business value provided. When we voiced the concerns with our new partner, the response we received was "We don't work that way, but we'll see what we can do...".
Partnership? -- Lessons Learned
Right from the beginning, the relationship can be seen as adversarial, due mainly to a stark contrast in expected communication patterns and a drastic change in how business solutions are collaborated on and delivered for our company. When you ask someone to sign off on something, that's an agreement and a waiver of sorts. That's definitely not a partnership from the outset. It's a transaction.
Please note that I'm not claiming ultimate demise on this new partnership. Clearly, this doesn't mean everything won't work out in the end as very capable professionals at both companies will no doubt do whatever it takes to make this thing succeed. However, it's a tough thing for a company like ours to become pretty good at working in an Agile manner and then turn over implementation to another team from another company in another state that doesn't value the same things as we do.
It's clear that any business today will need to have a solid strategy for how to effectively leverage technology to achieve it's vision. When evaluating these strategic options that include partnering with another company or consulting firm, it's VERY important to keep in mind your company/team culture to ensure that the team concept is not lost in the shuffle. Culture in the situation described in this post means 'the processes, methods, and communication patterns that allow a team to get things done'. Mismatches in culture between companies and teams brings more obstacles to an already difficult task.
I'd like to know...how do you think strategic technology partnerships should operate today? What are your success/failure stories? Is it too much to expect third party vendors to adapt to their clients' way of working/culture? What are reasonable expectations here?
** Both the project manager and the technical architect from our partner expressed their company's inability to easily create a tenant's (that's us) environment in isolation so 1) at any moment we can easily see the progress on the deliverables and 2) it can be tested, among the other benefits of having the capability to automate environment/application deployments.