Plan for Success ... Be Aware of Reality!

I run hard! My teams run hard!  We’ve got a lot on our plates and the pipeline is overflowing.  As soon as something is done, there are 5 more things waiting in the wings that need attention.  That’s a good thing – it tells me that the business values the services that my teams deliver on and that we can continue to be a difference maker within the organization.

As we go about our business – we plan for success.  Delivering product and services that our Financial Institutions can use to succeed in the market and make a difference with their customers.  Over the last several years, we have built a process around activity that ensures that we know why we are building something, we know the success factors around what it is we are building and that we then can design, build and QA the stuff we are moving into our production environments.

The teams have done a great job of reducing the number of iterations built before code can move into production.  Translation, they’ve reduce the number of critical errors found during testing that requires additional iterations prior to implementation!  They’ve also significantly reduced the number of issues that require after hours support.  Our teams have worked together to reduce the overall amount of time needed to regression test our products.  We are doing automated nightly builds on our code and are well on our way to having a full suite of regression tests run along with the automated builds.

So why am I talking about all of this?  Well, to put it all in perspective, it doesn’t seem to matter how well we refine the processes and manage the activity, we still have things go wrong!

1. Requirements identified after development is under way. 
2. Designs between teams that sometimes conflict. 
3. Estimates of project activity that end up being woefully incorrect. 
4. Resource constraints across teams just based on the sheer volume of activity. 
5. Data issues within our test environments. 
6. Validation exercises that end up taking longer than planned.

You know the drill.  You’ve all seen similar stuff happen to your projects.  So what’s a team to do?  Well as much as we want to keep our rose colored glasses in place and see sunshine and rainbows, it’s our job as leaders and technical experts to measure and apply a dose of reality within our projects.  The organization is looking to us to deliver new features/functions into the production environment.  They don’t really care to hear about how we make the sausage or why it might be taking longer.  What they do want is a semi-reasonable date as to when the features/functions will be available and what it means to our Financial Institutions and our Acquirers.

So, translating back to our internal teams, that means we need to make reasonable estimates along the way and refine as we move through the process.  As technicians, looking at and identifying the tasks needed to complete the activity – you can’t assume everything will go the way you want and your estimates need to include the breathing room you’ll need when something unexpected pops its head up.  As project managers, you can’t believe everything you’re being told – you need to validate what is being said and ensure people are on track.  Depending on the complexity of the project, you may need to put in some buffer time between the various activities to ensure that the teams have time to stay on track and recover from unknown issues.  This may not be needed on smaller less complex projects, but as the complexity gets bigger, you’d better start thinking seriously about buffer space.

I am not advocating that you needlessly pad time into your projects to make a 6 week effort end up taking 10 weeks.  What I am advocating for is that project resources accurately evaluate their tasks in a realistic fashion and feed those numbers back up to the project manager – that includes identifying the riskiest tasks and ensuring that you’re not being overly optimistic on the estimates.  Additionally, the project manager needs to review those estimates coming in and ensure that the numbers are ‘good’ and make judgements on where additional time may be needed to address parts of the process that look to be difficult.

I’ll give you a perfect example within my own organization.  With our large enterprise wide projects, we perform an integration test within development prior to moving the code into our formal QA and Parallel environments.  We began this formal ‘integration’ test effort probably a year and a half ago.  This testing required us to ensure mock data was setup across various platforms and application silos that would allow us to take transactions across the entire ecosystem.  This was initiated to ensure that by the time the code hit QA that we had successfully tested input/outputs and application handoffs between the various silos.

When we initiated this new step in our overall lifecycle – we were extremely aggressive in how long we thought it would take us to build the environment, populate the environment with the correct data and then execute the integration test plan.  I kept pushing the team to get all this activity done within a short time window so that we could then get into the ‘real’ testing and move the project forward.  Whether planned or not – the time associated with this integration testing took longer than planned and we eventually had to account for that within our planning.  Now that we’ve been through several iterations, we are beginning to automate various pieces of the environment and data setup/configuration – this should help us draw the time back down

Our goals were right, this helped us implement code into production that had a higher level of quality, however, I created a set of false expectations within the teams on the durations associated with this activity and they needed to give me feedback to reset my expectations and identify the correct timeline within the overall project activity. 

If you'd like more information on my background: LinkedIn Profile

Timelines - Not Just Something To Look At!

I've spent the last two posts discussing the role of the Project Manager - what I think is important for the Project Manager to do within the role that they play and how they not only need to manage the assigned Project Team, but also how they need to manage across and up thru the organization to be successful. Today, I'm going to switch gears and discuss one of critical items that the Project Manager owns.  The Project Timeline - for the purposes of this discussion, I am focusing on Project Timelines associated with the development of software.

Project Timeline Definition: The timeline consists of a series of interrelated tasks and activities within a given period of time representing the work effort needed to deliver some set of functionality in to the production environment.

We've discussed the overall Project Lifecycle in several previous postings.  For the purposes of speeding the discussion up, I'm going to assume that everyone is familiar with the stages of the lifecycle that I've discussed:

1. Discovery - defining the box around the activity of the project, documenting the goals of the project effort, the expected deliverables, potential costs and any deadlines that must be met.
2. Requirements - detailing both the functional and non-functional capabilities, features and attributes of the project deliverables.
3. Technical Design -  detailing the technical road-map (Technical Specification) that will be used to satisfy the identified requirements.
4. Development - the construction of the deliverable, including infrastructure and application pieces needed to satisfy the Technical Specification including both functional (user features) and non-functional (response time) items. 
5. Test - executing regression and new feature/function testing to ensure that existing functionality was not broken by the introduction of new features/function and that the new feature/functions work as expected.  Would also include load testing to ensure that the system performs within accepted time parameters.
6. Implementation - Activity associated with moving the new system in to the production environment.  This includes the code delivery, database changes, parameter file changes and infrastructure changes in to the environment.

Even with the simplest project, some combination of the above phases of the Software Development Lifecycle (SDLC) will be executed.  All of this activity combined together represents the Project Timeline.  From the very first discussions identify what might or might not be included in the final delivery to the actual implementation and post-implementation activity needed to validate that the system is working properly and that end users can begin using the functionality delivered within the project.

As stated in previous postings, not every project needs to follow every stage of the defined SDLC process or create every artifact defined within the process.  However, every project needs the minimal amount of ceremony and documentation necessary to ensure the success of the project.  More complex projects will require more ceremony - simple projects will require very little.  No matter the size of the project, there is still a start and finish date associated with the activity of the project.  Some organizations may not formally begin tracking activity on a project until it gets to the requirements stage, and that's fine.  Whenever you begin - you begin, and that is the start of your timeline.

So why is all of this important?  Well, first and foremost, the Project Sponsor and the management team are going to be interested in the overall timeline and how current progress matches up against expected progress.  In other words, how is reality matching up to the rosy picture that was painted at the beginning of the project?

Now, for the Project Manager to really manage the activity associated with the overall project, there must be reflection points where the team can evaluate activity done on the project to date and reassess the remaining activity to validate current expectations as it relates to the overall budget, resources and the Project Timeline.  Within the organizations that I've been associated with over the years, we have established standard points within the overall SDLC process where this assessment is performed and the results then communicated up to the Project Sponsor and the Senior Management Team.  In the organization that I currently work for, we formally handle this after each of the following milestones:

1. Requirements Completion: This is the first chance to validate the high level timeline initially envisioned when the Project was first initiated.  By this point everyone should understand what is going to be delivered, the touch points between the various systems/sub-systems, whether new infrastructure will need to be deployed and what testing/validation may be necessary.
2. Project Level Design Completion:  At this point the Technical Specifications have been generated and assumptions from the Requirements Phase have been validated.  Information needed to understand what 3rd party pieces need to be incorporated in to the delivery have been identified and initial cost-estimates are available, internal labor has been estimated and specific touch points between systems have been identified.
3. Detail Design Completion: At this point, the team involved in the construction of the system have been involved and taken the Project Level Design (Technical Specification) and turned it in to actual directions that the Software Engineers and Infrastructure Engineers will follow to create a system that satisfies the Project Level Design (Technical Specification) and ties back to the Requirements.  All activity/tasks related to the project have been identified and estimated.  All external costs have been confirmed.  All internal labor costs have been identified.

After the Detail Design Completion is hit, the Project Manager is responsible for establishing the final baseline.  To be honest, we currently are establishing baselines at each of these reflection points.  We are then using that information and feeding it back in to the teams to help them as they generate estimates for new project related activity.

At each of the above reflection points you are able to provide updated budget, timeline and resource estimates to the Project Sponsor and the management team.  This will be used to validate whether it still makes sense to pursue the project - or if the approval to move forward needs to be revoked.  

Why would they revoke a project that has made it this far in to the SDLC?  Any number of reasons:

1. The project no longer makes economic sense.  Initial cost estimates were too optimistic and did not account for all of the activity within the project, both internal and external.  Final labor costs or licensing costs may make the project unviable.
2. The Project Timeline does not allow the business to achieve the strategic goals associated with the identified deliverable.  Maybe the project had to be delivered by a specific date to beat a competitor to market and missing the date means missing the sales potential.
3. The defined deliverable no longer provides the competitive advantage necessary to gain in the marketplace.

As Project Manager, it is your job to establish additional milestones within each of the phases of the project to gauge whether the team is on track.   This also means looking at on-going activity within the project and the activity of individual team members to ensure that they are spending enough time on their assigned tasks to keep current activity aligned with the planned activity.

1. Did you allocate a resource full-time to the project?  Are they actually staying focused on assigned tasks and spending their workday on your project?
2. Was their a production issue that diverted assigned project resources?  What impact is that going to have on the overall timeline when they just spent the last four days resolving an issue for one of your largest clients?
3. Is activity on another project impacting the ability of assigned project resources to work on your project activity?  Your most senior developer has been stuck working an issue for the last 3 weeks on a separate project integrating code with a 3rd party who has been unresponsive.
4. An external party missed delivery of promised code or infrastructure pieces that are critical to the delivery of your project and they can't delivery the necessary functionality for another month.

There are a lot of things that will end up impacting the overall Project Timeline.  The Project Manager needs to continuously review current status against the plan and then work to remediate slippages identified within the overall Project Timeline.  Many times, the Project Manager will be able to do this without escalating up the chain.  However, some issues will require that the Project Manager escalate issues to the necessary resource manager, Project Sponsor, PMO, other management team members across the organization or the Senior Management Team for resolution.

How are you managing the Project Timeline within your organization?

Tags: Project Manager, SDLC, Project Management, Project, Management, Manager, Lifecycle, Software Development Lifecycle, Development, Software Development, Project Timeline, Timeline

If you'd like more information on my background: LinkedIn Profile