Prefer partnering with craftsmen over contractors

If you are in an IT department in one of the bigger organisations working in the major verticals of banking, telecommunication, insurance, retail etc... you are probably looking at a portfolio of work which has major bumps in the curve when starting a big software initiative and a steady state when those initiatives move to a steady state of enhancements and bug fixes (a.k.a Business as Usual (BAU) ).

If you are someone responsible for delivering this portfolio of work you probably are tied under the typical IT budget constraints of a big organisation. Hiring highly skilled people quickly to deliver the bursts of projects that come along is going to be difficult. Given this scenario it is more than likely that your attention goes to the right end of the curve where you see the amount of work in the portfolio reducing within a number of years. This is when you think "Why do I need to hire more permanent staff, I can get things done by hiring contractors who can then leave when most of the work is done."

This might probably work if the contract staff form a very small percentage of your overall organisation. You might even be able to find some real good contractors who specialise in certain niche areas which might be temporarily beneficial to your company.

But the moment you start relying on contractors to do most of the work in the pipeline, it is the beginning of a big world of problems. Because here is what will most likely happen.

• You decide on hiring contractors to get some major pieces of work done.
• Since these contractors are temporary, you ensure that you have enough permanent staff to oversee the work the contractors are doing. You have most of the permanent staff in all the important decision making roles.
• The contractors come in and start working alongside your permanent staff. The good ones want to drive new initiatives within these projects but soon get frustrated by the red tape approval process created by your permanent staff.
• Your permanent staff start feeling insecure about their jobs once they see some contractors who are better at the job than themselves.
• You might try to hire these brilliant contractors which creates an ugly set of dynamics at work.
• The contract staff becomes frustrated and start working just the hours required for their contract. If you hired really cheap contractors then they are probably in this mode from day one.
• The permanent staff has issues with the quality of work done by these contractors and sometimes vice versa.
• You add rigorous shortlisting processes for contractors in a bid to weed some bad ones out. But you still end up with some bad contractors because of budget constraints.
• Your project ultimately might go live but chances are that the quality of the architecture, codebase, user experience , performance is worse than ever. Your business stakeholders are unhappy.
• The contractors leave and you inherit a horrible quality system.
• Your permanent staff feels terrible maintaing this poor quality system. They either suggest a complete rewrite of the system again or suggest outsourcing the maintenance of the system to contractors.
• Another project comes along and you are probably still choosing contracting firms in the never ending grind of work.

So is there a better solution ? Let us look at the assumptions again

• Most systems you are building are of strategic importance to your business.
• There is more work in the pipeline than the permanent staff can chew and to be delivered in an aggressive timeframe which does not allow you to hire more permanent staff.
• The inflow of work might reduce after most IT systems are up and running in a few years.

and of course the more important long term goals that

• You need to be build a high quality system or platform which scales well to serve the business needs.
• You need to build an IT department with skilled technical people who are able to deliver and maintain the systems required for the business

So it is in your best interest as someone tasked out for delivery to build good software and at the same time set out to build an organisation which can do the same repeatedly in the future.

This is best done by hiring good people in first place, but if for various reasons you cannot, then at least try to partner with people who are passionate about the craft of building software than people who worry about billing the 8 hours of work.

To scale, try to find companies with whom you can partner with for their delivery services knowing how culturally passionate the partner company is about delivering the work for you. (And believe me , there are many good consulting companies out there which can help you out).

And by partnering, you engage with them at levels where they have a decent voice in decisions made on how to deliver the project. There is transparency and a drive towards building a win win collaborative culture within the team. You treat them as strategic partners rather than augmented resources in your delivery organisation .

It takes time to find such companies to partner with. You need to validate their delivery capability and culture fit over a period of time. But once you have done that, try and build a lasting relationship with them because in reality you will always have a backlog of work given the dynamic nature of your business.

After all, you are building long term assets for your company and it can best be done by partnering with people who care about it the same way you do. So invest in finding a good software delivery partner that can work for you instead of risking long term failure by using low cost/quality contractors.

Why you should care about experience design and continuous delivery as a project manager ?

I had written earlier about how a good project manager in a mature Agile team needs to go beyond managing scope, time and budget to be really effective in his/her role. The key is to understand the product and the tools and techniques used by the team to build it.

But there is more a project manager should do, which is, to provide the right direction to the team. The focus shifts from "building the thing right" (i.e delivering within scope , time and budget) to "building the right thing" (a product that fits the purpose the business and its users).

Building a delivery engine that can react quickly to market feedback and adapt needs focus in a few different areas than traditional project management. And this is where project managers should have a good understanding of experience design and continuous delivery.

From a continuous delivery perspective a PM should have a good understanding of

* The level of automated testing required to certify almost production quality builds in no time.

* The value of using a production like environment for testing and feedback.

* How automated deployments can help speed up time required to deploy to multiple environments and rollback quickly if the need arises.

* The need for real time monitoring of production systems for the team to quickly respond and fix production issues.

* How one can benefit from feature toggles v/s branching.

* The advantage of releasing quickly and minimising work in progress to shorten the feedback loop.

The main advantage of continuous delivery is not so much in reduction of deployment and maintenance costs. Instead it is in the capability it provides to validate and adapt the product being buit quickly based on end user testing and research.

It is important , as a PM to know

* If we are doing enough user testing to validate what we are building at regular intervals ?

* Are we doing enough user research to provide critical user context data in the form of personas etc...?

* Do we have good analytics capability built in the product to profile usage patterns which can help us make informed decisions about the product?

An insight into some of these aspects can really help a project manager steer the team towards building the right product which is way more valuable than someone who ensures the team is tracking to an outdated plan.

Models of a Project Manager role in an agile project

The roles a project manager can play in an agile project are endless and a lot depends on where one’s interest lies and also the type of project one is working on. Again not all of these roles are applicable to all agile projects.

Here are a few possible options

The Iteration Manager

This is the most hands on delivery role one can do as a project manager on a team. The work largely involves planning iterations, resolving blockers from the daily stand-up, ensuring a smooth passage of stories across the story wall.

It requires working closely with all roles within the team and understanding the core practices of writing a user story to the essence of continuous integration

Program/Project Manager working with Iteration Manager(s)

If a project demands a larger team, with multiple parallel work streams, one might need an Iteration Manager for every decent sized (3-4 developer pairs) work stream and an overall project manager looking at work across teams. Depending on how large the project is the role is often termed as a “program” manager.

The work involves managing functional and technical dependencies across work streams during upfront release planning also during regular iterations . It also means providing an overall program status to senior stakeholders with the necessary abstraction of details.

Release Manager 

If it is a large enough project which is making multiple releases into production, there could be a need for a full time release manager role. Work here would involve planning upcoming releases and tracking stories and defect fixes are merged across different branches. It also requires a decent understanding of the techniques and tools such as continuous integration, version control systems, branching strategies etc.… to engage in an effective dialogue with senior developers on the team.

Project Manager working with a vendor PM counter part

If a lot of work is done by vendors either outsourced or co-sourced, there could be a need for a client project manager who can work across with all the vendor PM counterparts. Typical work of a client project manager involves resolving issues in the project dependent on decisions from stakeholders within the client organization. This could mean things as trivial as getting environments setup by the client IT team, to as complex as escalating critical issues about the product delivery to senior stakeholders from the business

The vendor PM(s) here acts as a project/iteration manager working closely with the client project manager every iteration.

Client Account Manager

A client account manager can become a full time role for a vendor executing a big project for a client. Major part of the work involves managing the ongoing client relationship by being part of key conversations with the senior client stakeholders, project sponsors etc.…  Work also includes billing and invoicing the client for the services offered.

A client account manager with a strong de livery background can assist a lot in having difficult conversations with a client when there are delivery issues within the project.

Release plan checklist

When I build release plans, or even look at release plans of other projects, I end up running through a checklist of things in my mind, to determine if it is good enough. If you are an Agile PM trying to build a plan, this could be useful for you.

Iterations	Is the length of the iteration enough to be able to complete a medium size story within it ? Do the number of iterations fit well within the acceptable timeline ? Can we assume a production quality build after every iteration ?
Estimation	Are the stories sized relatively ? Does the team understand the estimation unit across all roles ?
Velocity	Is the planned velocity, the average velocity of last 3 iterations ? If its a new project, are we planning based on a raw velocity exercise ? Are team members across roles in planning the velocity ?
Resource ramp up	Is there time  factored in  for new people to ramp up on the team ?
Ordering of stories	Are the stories ordered around the critical path functionality ? (Always remember the critical path determines the schedule) Are the higher priority stories slotted for earlier iterations ? Are the stories ordered so that they meet any functional or technical dependencies?
Negotiable Scope	Are there some “nice to have” stories in the plan which can be later negotiated if need be to bring the project on track ?
Spikes / Proof of Concepts	For technical unknowns, are there spike stories which allow the team to explore technical solutions ?
Non functional requirements	Is there clarity on requirements for Performance, Security, Scalability and how they are going to be addressed ?
Functional Automation	Will developers do functional automation as a part of a story or this will be done as a part of QA ?
Regression/Stabilization	Is there a need for a separate regression/stabilization iteration once the development is complete ?
User Acceptance Testing	How much time is required to UAT the set of stories the team will deliver ?
Risks	Does the team understand how much risk is there in the plan ? Are these risks shared with the customer ?

What's next that can go wrong ?

When developers on my team are developing the next priority feature, testers trying to break the application, I am busy looking at what is the next possible thing that can stop the teams progress. There is that one area in the application which can possibly bring up a big performance issue and I have no one looking at it yet. There is a UAT phase coming, and some services have not yet been integrated and we might get a lot of surprises when it is too late to recover.

I have started enjoying this as a project manager. Think , think and try to think of things that no one else is thinking just yet. And I know I cant just get into every bit of detail, I will have to trust the leads from each role to ensure that all aspects are covered. I ask my QA lead atleast once a day about what we should be doing 2 weeks from now. He is currently busy getting QAs to test critical features which developers are churning out, but a peep into the near future helps him reassess his plans and make correction. He tells me he needs a few new test environments which were not planned earlier, and I immediately make a note of it. We quickly catchup on plans for shipping future builds and expectations I as a PM should be setting with our customers.

Looking into the future and managing risks becomes a routine task for me. Getting the team to be ready for the next uphill task becomes a big motivation in itself.