How to get a software project done on time.
Getting your next software project done on time can be a matter of factoring a whole lot of variables. Time, resources, features and not forgetting the client's feature creep.
Now before I get flamed for trying to document "the impossible" or get any more "keep livin' the dream, buddie" tweets, let's look at the basics - again. Software and web projects CAN come in on time and on-budget but the same old factors keep killing them.
So while it's the dream of every PM to hear "We Did It!" when the dev team finish code review, it's also pretty clear that it doesn't require a nuclear scientist or psychic to know that this does not often actually work out perfectly. While our client's might like to forget it at times - we're all human.
How much time are we spending with clients talking about why we didn't make their schedule given the constantly changing spec we should be "more carefully managing"? Or in the postmortem where we bemoan that there were just too many moving targets to manage in the solution, making time or budgets just a wishful notion we're always chasing.
Cynical thinking aside, virtually every project I've worked on starts out with the best intentions and a keen and motivated team. So - let's start completing some more projects on-time and on-budget. Regardless of whether we want to walk out the door before it gets dark or sleep in to 8am, it's time to get serious and organised.
For what it's worth, here are the simple steps I try and follow for getting a team over the dev-hump and back into productivity - and the pitfalls I find that kill-off all of those best-laid plans, morale and intentions.
The First and Most Important Step! Create a plan with simple, realistic and achievable goals.
In all-too-many cases, the goals and timelines may be set by sales, or the Resource Creep (that blue beast that no-one knows who lives down the corridor!)
If you're already running 'behind the eight-ball' when you're thrown into the couldron, the first step is to find out what resources will be needed - and create a resourcing plan for commencement. The urge to document how we're going to solve the Kennedy assassination, find the frisbee that slipped into the Bermuda Triangle or build documentation to rival the next space station launch may be overwhelming. But resist the urge and JUST document what's needed to kick off a reliable first project phase or proof of concept steps initially. Then, once you know where your resources are coming from and how the POC is going to roll, get the detail under control - working out what will be needed to complete on-time and assess impacts on schedule if resourcing is changed.
Needless to say that, it's time to flag penalties for missed deadlines and contractual challenges with the sales and management teams if there's holes in the resourcing plan. Sometimes delaying kick-off can be better than failing to complete to-schedule if the client is made aware of the resource allocation issues upfront.
Assuming you now have a proof of concept moving, focussed resources and management buy-in, it's time to dust off Microsoft Project or Excel if you're more comfortable with that. Add in your resources, project milestones and keep the plan alive. Engage the team and start drawing out the key break-points in the development.
Carefully managing the resource engagement model can be the difference between success and failure in step one. But beware of the Resource Creep.
If things are still looking bright, we're onto the Second Stage - Task Assignment.
If things have gone well and your resources are fired up (and the RC - Resource Creep - is on assignment elsewhere), you're off to a great start. With your Project Plan growing and the code and architecture planning underway, the days will be looking bright! It's time to convert napkin architecture and customer's whistful notions of functionality down to achievable functions.
Once you have a basic functional design, it becomes easy enough to assign functional clusters to each member of the team - Whether it's User Interface, Data Modelling or Database design task-clusters, these can be used to achieve milestones and proof-of-concept test-points quickly and itteratively. Task Clustering is also an excellent way to ensure the team feels a sense of achievement in their patch plus keeps the team accountable for completion. (Accountability coupled with a sense of achievement remain the key motivators. But removing either one of these will destroy the project.)
Each task-cluster needs a realistic time on the project plan. And this needs to be carefully thought through with the team-member - not randomised on a MS Project Gaant chart. Project Managers constantly forget how quickly poor time-estimates can compound on a Gaant chart. Each 48 hour off-set can quickly compound to a month delay on large enterprise projects.
With larger focussed development teams, it's not uncommon to have each team-member sign-off on a copy of the project plan their task-cluster's schedule. Each person may then be incentivised on completion of each segment or cluster of work to the promised schedule.
The Third Stage - Running the Gauntlet... erm Schedule.
So. The schedule is prepared and the stage is set. The team have agreed on their workload, architecture and a path has been mapped out for the initial task-clusters. The Proof of Concept technology tests worked. There have been no serious revolts or uprisings amongst the ranks and senior management are probably now cursing the fact that the Sales Team's assessment that "it can be ready yesterday" wasn't actually accurate.
The good news is that the worst is hopefully now behind us. If we're organised and want this to work, the key in this phase will be resource visibility. Keeping everyone accountable to each-other. Producing Gaant charts (preferably on paper as well as using MS Project Server if you have it available) and sticking them on the wall amongst the team. Seeing the resource plan for the first time shouldn't be a religious experience of enlightenment (!) As we've all worked out, most professional programmers only have two hands and one task-cluster will need to be under control generally before another can be started. Everyone needs to be reminded that the schedule can be their friend not their enemy.
The key in stage three is therefore, aside from warding off the Resource Creep, simply controlling the key and critical development milestones of the project. Highlighting them on the Gaant chart and ensuring that task clustering is working to achieve these key elements. As a few of these clusters or elements start showing up in the code repository, a test plan will need to be introduced to test any logical workflows against the plan. Committment to the plan and to the timeline needs to be reinforced yet-again. The big danger when a project is running in stage three is that the Resource Creep grabs your resources for that other project's "quick fix" and small delays start to compound into morale-sapping nightmares. Show me a team that never catches up and I'll show you a team with resume's on Seek.com or that's lost the will to fight!
At the first sign of a pontial delay, the temptation is to drop functionality to recover - compromising time before fixing the issue's core can be the root of a failed deliverable. Keep the overall plan running to the FFS - A Full-Function-Schedule. While the matra around the office may well be "FFS" everytime the project team talks about resourcing, maintaining a Full-Function-Schedule and sticking to your guns is usually the right way to get a project completed with a happy client - But it won't always be the best career path!
Assuming task-clusters are starting to arrive, it's time for the FFS Critical Path review. Working through the functionality list and customer requirements document, a set of workflows should be clearly evident. These should be documented and form the basis of your Test Plans. The Critical Path will essentially be based on ensuring these workflows pass the test plans and can be demonstrated as the initial releases start coming together.
Team communication becomes one of the most critical elements as the project progresses - Integration of task-clusters becomes the next challenge. This can be tricky as each team-member's KPI may depend on working with another team-member. So your job as a team-lead can start to include such fun as politics and time management skills. Not to mention a few "you call that a sniffle" challenges (!).
Stage Four - Who ate the Schedule-buffer?
We've all had those projects where the Swine Flu hit, or the Tsunami caused a ripple in the programmer's bath-tub. We've even realised too late in the schedule that people actually "Have a Life" and feel that their aforementioned life should be grounds for getting leave. So , no matter how much you try, hiccups in the schedule are a way of life in the coding world. Minimising the potential for disaster through solid planning and jealously guarding your team can be an artform. For software development projects a standard buffer of 25% across the project timeline is the accepted variance for a realistic delivery on a 3-6 month project. If you've eaten it and you're only half way through the code-base, it's time to revisit scheduling before things go way off the rails.
Stage Five - Resources Again and Brooks's Law
You're working your rear off and the task clusters and functionality models are coming together. Proof of Concept phases worked - showing up the issues in the architecture for action items in the plan. You're feeling confident. Team deliverables are on-schedule and everyone's smiling for a brief, unexpected moment. This is not the time to relax. It's the time to take-stock of the resource situation and look at how your buffer is going. Assuming your project is properly funded (someone is actually paying for this?) and kicked-off with realistic assumptions and expectations, there will be plenty of good reasons to spend a little extra to resource up the project now, not resource it down to ensure it all goes well. Good practice at this point is to build your buffer up not down. Why? Because the worst estimations in any software development project are usually based around testing and bug management pre-release - Not in the design or POC phases. Remember the 90/10 rule? If you don't have a 'clean slate' on your buffer now, it's time to fix this.
The most foolish and ill-thought out project management slogan around has to be Brook's Law - "adding manpower to a late software project only makes it later". Brooks himself called it an "outrageous simplification". And who am I to disagree. Adding resources in a panic does indeed cause pandemoneum. Managing a well run resource model, knowing what the learning humps and integration curves look like, can indeed save a project from distaster. Why do project managers keep brandishing the foolish notion of Brooks's Law without thinking through the quantity, quality and skills of the teams in play. Good management and development methodologies can have a dramatic impact on Brooks's Law. Assuming that all teams will immediately suffer the full impact of "Brooks's Law" just by implication is a endictment on the project manager's opionion of his team's technical and coping abilities. Who's making these calls on resourcing? A project manager should be accountable AND in control.
Once again, beware the Resource Creep. Assuming you've got this far and resource adjustment isn't a result of being blindsided or through a sudden mandate to "share resources", you should be heading towards a successful development phase - resources and buffer adjusted and with a clear test plan forming. You already guessed it (it's getting boring now?) - Re-assess and mitigate the negative impact of resource allocation by checking the buffer available - remembering that the over-run will almost always be in the testing / final clean-up project stages.
Stage 6 - Ongoing Progress Tracking as the project heads into testing.
Throwing in another three letter acronym for good measure. OPT or Ongoing Progress Tracking is something you're either good at or are terrible at. It usually gets a fair few "FFS"s if a programmer thinks he runs the project - and we're not talking about schedules now. Usually a determiner of a cohesive or fragmented team model,will be the ability with which you can get a straight answer out of your team on how their task-clusters are going. This will also determine how close to schedule a project rolls. While often discounted outright, a well run project whiteboard or A2/A3 printed Gantt chart for each project segment can do a lot of keep everyone communicating and accountable. Don't be afraid to run the project as a technology project - from the top. Management describe functional models, business analysis describes workflows based on documented client requirements (and therefore test-plan scope) and project management describes task-clusters. This works a whole lot better than allowing programmers to sink the team with 'architecture' and political discussion. That's not to say that the tech team cannot add critical value in software design and architecture - it is simply a statement that the value-chain needs to be directed by project management.
Remember to celebrate the wins with the whole team, successfully delivered milestones and test plan successes. The wins belong to the team - not just management. Keep testing against the Critical Path plan and keep the customer's deliverables top-of-mind. Facilitate results, keep the team talking to each other and manage bottlenecks wherever possible. Assuming the project resources have been tweaked, managed and are still talking successfully to each other, then you're now entering the Test Plan phase. If you're stuck with team in-fighting, it may be time to rethink the team's members. Critical Path meetings to maintain schedule adherence and manage any required Critical Intervention are now the order of the day. Whether you follow Extreme Programming (XP), SCRUM, or another Itterative development model, problem solving often means more in terms of meeting team-related objectives, that are both understanding or technical in nature, head on and solving them as they happen rather than in terms of managing the code itself. Good coders are team-players - End of story.
Keeping the team focussed on the result, ensuring the team works well together and enjoys working in the structure they have formed is critical to productivity. Constantly changing the structure and make-up of teams can dramatically impede productivity - So decisive action and consistent planning is mandatory to software development teams - not just the project they are working on. The task-clustering and teamwork approach itself needs to drive - destabilisation does not succeed nor motivate. If a small software development team is constantly playing 'musical projects', it's time to change either the team or the business model.
In most enterprise software developments it seems like every failure in the schedule or test plan means the end-of-the-World as we know it. You're sure the team will torch your PC, burn the cat and your family will emigrate. As the Hitchikers Guide would say "Don't Panic". Job number one remains leadership. Providing a voice of reason and sanity and calmly leading the troops out of the storm is what it's all about.
If the Resource Creep has struck, regroup, refocus and try and rebuild confidence in what can be salvaged ...
Filed Under: Education in Technology • Jobs in Technology
