Agile? Waterfall? - Pick Carefully or Pay the Price!

Managing projects across an enterprise is an art as well as a science. There are several well known paradigms used by organizations across the world - waterfall to agile with variations in-between. I have always told those that have asked that there is not one silver bullet to magically solve the project management puzzle. In fact, my recommendations to people have always been to create a project management paradigm that fits the culture and needs of the organization.

My teams work in an industry that is heavily regulated by state and federal agencies and also must conform to several industry governing entities that set standards within the payments space. Many of the projects that we work on are implementing standard interfaces between the various payment networks, acquirer, issuers and other players within the financial industry space. Implementing these interfaces is a technical exercise with very little to no user interface. You either get the spec right or the money doesn't move. These initiatives really are not setup to be run utilizing agile techniques.

Now, let me shift over to some of the other initiatives we run within the organization. Our mobile and internet applications. As you can probably guess, these applications have significant user interfaces. These project efforts can utilize and benefit from agile techniques that can give our 'user representatives' much quicker access to potential solutions as well as drive increased cooperation between the development, user and quality assurance teams. This is a place where our teams are experimenting with agile techniques as a way to accelerate delivery through the development channel.

One organization utilizing different project management paradigms based on the unique needs of the initiative!

I'm running at this from two different directions at the same time:

1. I'm working with our project management organization to review our overall defined lifecycle to recommend changes that will allow projects that might benefit from being run utilizing agile techniques to take advantage of a slimmed down process.  We still need to figure out how to satisfy the documentation requirements of the various state/federal agencies and industry governing bodies, but overall, they are supportive of our desire to create multiple lanes that can be managed differently based on the overall risk of the effort.
2. I'm encouraging our project managers and team members to challenge the process. When working any individual initiative within the overall portfolio to make recommendations to skip various project artifacts, project steps or entire slices of the overall project lifecycle. The key is to document the decision as to why decisions are being made to skip certain pieces of the lifecycle based on risk and impacts to the overall effort.

This is what works in the enterprise that I currently work for. 

On a regular basis, I have to sit across the table from auditors and prove to them that all of the appropriate documentation has been generated. That there is traceability though the project effort from requirements, through design and testing. I have to show them our implementation and fallback plans as well as prove that those plans were followed during actual implementations. Our auditors will randomly pick projects and then go through all of the documentation and measure it against the documented lifecycle to ensure that it's all there. If something is missing, there has to be proof - either through project meeting notes or via change requests - that show the decision was made to skip the document/project step(s). This proof also needs to discuss the risk to the product, the enterprise, our financial institutions, acquirers and/or processors. It is the goal of our project management organization to manage these risk issues and ensure that we are safeguarding our ability to process payment transactions and move money within the payments space.

In past lives with other organizations I've run the gamut from running lifecycles that are even more formal than the one my teams currently use to running very informal lifecycles similar to the agile paradigm. The key is understanding the culture of the organization, the risk tolerance within the organization and the  time to market pressures within the industry.  As leaders within your organization, it's your job to discuss these issues and build processes that match the particular needs of your organization, manage the risk to the organization and your customers and build a project lifecycle paradigm that can deliver.

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

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

Capturing and Using Milestones - Managing the Plan and the Portfolio

So, the last time we chatted I discussed the importance of milestones.  With this posting, I'd like to run through the milestones that I use, explain why I think there important and discuss how I'm beginning to use them within the overall lifecycle.  For purposes of this discussion, I'm focused on the resources and time components of the project.  We can discuss the "real dollar" budget vs actual in a later posting.

Let's get started and dive right in to the discussion. 

As I've discussed in previous postings, my teams use MS-Project to plan and track our project activity.  Each project is assigned a unique project number and name.  The project number is used to assist in standardizing many of the project artifacts that get created throughout the lifecycle.  The unique project number is used on op level artifacts that define the requirements and technical specifications all the way down to defects logged so that we can tie all activity with a project back together.

The Project Manager has the responsibility to create the project file.  They use a standard template that has been updated and modified over the last four to five years. 

• NOTE: This is important once you create our template (or any other project artifact) don't let it sit and collect dust.  Occasionally, you need to go in and dust off the artifact, in this case the project template, and see if everything still makes sense.
  
  • Do you need to add or remove default tasks?
  • Do you need to reassign default resources?
  • Does it make sense to update the time frames (start and finish dates) associated with default tasks?
  • Do you need to restructure the predecessors?

The template has sets of default tasks and milestones that we have defined for each of the six phases of the lifecycle that we utilize.  These tasks and milestones identify standard activity that normally occurs across the various teams involved within the lifecycle.  Some of these tasks are business functions, some of the tasks are technical functions.  So, from a management standpoint, I'm interested in several things:

1. What are the stop and finish dates for each of the identified phases within our lifecycle?
2. What is the point where we have enough knowledge where we can identify a target delivery date with a high degree of confidence?
3. Is activity on track to hit the identified target dates?
4. Are we on track to hit the baseline targets - or does the project file indicate that we will miss the milestone dates?
5. How do the start and finish dates within a given phase track against the overall projections used in portfolio management?
6. Are the resources projected within the portfolio accurate against what is being tracked in the actual project?

Within each of the six phases of our lifecycle, I want to know the start and finish dates of specific activities - these are my milestone dates.  So, automatically, across our six phases, I'm keying on the start date of the given phase and then a milestone towards the end of the phase that signifies that we consider activity within the phase complete.  Sometimes, there is trailing activity following the "finish" milestone.  That's why I can't necessarily rely on the finish date shown in the summary task.  For most organizations, you can probably get away with relying on your start and finish dates within the summary task - however, there will be some organizations that are like mine where there is some miscellaneous activity that goes on that you don't necessarily want to recognize as holding up the next phase of activity.

Next, we need to know when we are going to deliver the product in to production.  We can do all the planning and building that we want.  But the Marketing and Sales folks generally want to know when it's going to be available.  In many cases, they have marketing plans and communication strategies triggered by the implementation date.  Within our lifecycle, we have a standard milestone triggered at the completion of our Detail Design activity.  This is when we place a stake in the ground and commit to a delivery date.  (Side note, as with all things in life, sometimes we end up missing the date, but this is our internal commitment.)  Once the Detail Design is done, we create our final baseline (notice I said final baseline).  Once the final baseline is in place - that is what is used to create final stats at the end of the project.

Here is where it get's interesting.  On a daily basis, we have created a program that goes in and extracts these milestone dates from all active projects.  As well as collecting the milestone dates, the routine also captures the identity of all resources involved in each of the six phases of our lifecycle.  (This routine will be expanded to also capture the baseline dates stored within the project file.  No, I haven't perfected the whole thing yet.  We still continue to iterate through this and mature our lifecycle and metrics.)  This routine, also goes in to the Master Portfolio and extracts the estimated start and finish dates for each phase of our lifecycle as well as the resource projections.  All of this information is extracted and placed in a data mart.

So, at this point, I've extracted and recorded in the data mart, the estimated start and finish dates based on our Master Portfolio, the actual start and finish dates according to the Project Plan, the final baseline start and finish dates and the milestone activity identifying completion of our Detail Design where we establish our final baseline.   On top of all this, I have the projected resource allocations through each phase as well as the actual resource allocations recorded in the Project Plan.

On top of the data mart, we have created a web site that allows us to drill in to any given project: active, on-hold or waiting to be initiated.  The web site allows us to compare the actual plan against the overall portfolio projections both from a timeline perspective and a resource perspective.  As a manager, I can begin to answer the questions from above.  I can compare actual the start and finish dates of each phase of the lifecycle to the baseline dates as well as the portfolio dates to see if something has changed and if we need to make adjustments.  I can tell if our initial estimates are off and whether additional resources have been assigned to a given phase of the project.  I can tell when something has slipped that will impact our overall delivery date.  I can mange to the exceptions and initiate conversations with the Project Manager when I see something slip or when a date suddenly moves up in the schedule.

This is what works for my organization and what has allowed us to significantly increase the number of projects moving through our pipeline and increase the pace of activity.  We are by no means finished, we continue to tweak our lifecycle and the way that we are managing our projects.  But, based on the statistics drawn from these metrics, we have made a difference in the way projects are managed within the organization.

Speak up! What milestones are you using and more importantly how are you using them within the projects you manage?

Tags: SDLC, Project Management, Timeline, Tasks, Milestones, Budget, Template, Management, Projects, Software Development, Applications Development

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

Standard Milestones - What you want consistency?

If you're creating your project file from scratch for each project that you're managing, I have a short and simple question for you.  Why?

Step back and take a look at the projects that you're managing.  They all have the same phases (ok, small assumption here, I'm banking on the fact that you're preferred process within your organization is not a seat of the pants process).

1. Someone came up with an idea and sketched out the scope of what they wanted done.
2. Someone decided to flesh out that idea and put some requirements/stories to the idea.
3. Someone got involved and created a design for what the product would end up looking like.
4. Someone took the idea, requirements/stories and design and built the thing.
5. Someone then decided to test the thing to make sure that it worked.
6. Someone had to move it in to the production environment.

Now, maybe your organization is small and that "someone" was the same person start to finish. Or, maybe your organization is a little larger and you have dedicated teams doing all the work.

Regardless, if you are the Project Manager on any size project, it is your job to manage all of this activity.  Now, I personally don't care if you're managing all of this stuff inside of MS-Excel, MS-Word, MS-Project or some other tool.  I have always chosen MS-Project because I like it, others have differing opinions and I'm not going to pick bones about the specific product you use to manage your projects.  I want to talk about the way that you use the tool.

A couple of key points:

1. If you haven't created a template for the projects you manage - that's step 1.
2. If you don't have a set of standard milestones that you manage to within your projects - that's step 2.
3. If you don't pull data out of the plan and measure it regularly - that's step 3. 

As Project Managers we should not only be looking to manage activities within our projects to the 3 standard goals: time, money and resources.  If we are really doing our jobs, we are also trying to eke out efficiencies along the way.  One of the primary ways that you can drive efficiencies within any process is through standardization.

If you standardize the way that you run your projects - the team members that you use for projects know what to expect.  It makes it easier from project to project - they know what information you're looking for, they understand how you want it communicated and through the use of standard milestones, they know what goals you're driving to and what is important.

Just as important, the project sponsor sees a consistent set of milestones and metrics that you are using to drive your projects.  They begin to get a feel for what things are important to know about within the project, they understand how to begin looking at standard milestones to get a feel for whether the project they are championing is on track, whether resources might need to be reallocated if certain pieces of the project are falling behind, their confidence level in the process goes up as they see measurable data vs feel good talking points.

You can find plenty of standardized templates on the web for software development - though I highly advise against just pulling one down from the internet.  In previous posts, you've seen me rail against taking someone's idea of a SDLC process and cramming it into your organization.  The same is true for project artifacts - including the Project Template.  The Project Template should be driven by the culture of your organization.  It should include the phases that your organization and team feel are important, and it should include the tasks and milestones that you feel reflect the work effort that your company and team value.

There is a fine balance between not enough detail in the plan and too much detail in the plan.  Hint - err on the side of simplicity.  Start small and add additional detail as there is consensus across the organization that more detail is needed.

So, you're probably wondering - what's the difference between a task and a milestone?  Good question!

1. A task represents a package of work to be completed within the overall effort of the project - it is a tangible delivery that has resources, time and budget.
2. A milestone is placeholder used to signify that a collection of tasks have been completed and by itself does not have resources, time or budget.  Milestones represent points of interest within the overall SDLC that allow the Project Manager and Project Stakeholders to make judgements on the progress of the overall project.

Now, that you've generated a project template and you've standardized the milestones within your project - what do you do?

Okay, here's the secret sauce - first take a snapshot of the overall plan and establish your baseline schedule.  Only update the baseline if the Project Sponsor agrees that the overall timeline, budget or resources can change - or, if within your process you have identified specific points within your lifecycle where you re-establish the schedule and then reset the baseline.  (Typically, many organizations reset the baseline once final designs have been completed and they have a firm understanding of the development effort.  Within an Agile process, this would represent each sprint.)

Once you've baselined your project - you can begin analyzing activity within the overall project and reference the baseline.  This allows you to:

1. Identify slippage associated with dates - things that get done faster usually aren't a problem.  Understanding when things are going to take longer than expected is when the Project Manager really needs to step in and drive activity.
2. Identify cost differences.  If you're using your project template correctly, you're not only accounting for resources assigned to specific tasks and the timeline for each task.  However, I'd challenge you to go one step further and track all of the equipment and software that need to be purchased for the project within the Project Plan.
3. Identify when resources are over-allocated - this is a huge need within most organizations.  Anecdotally, they can tell when resources are swamped, but they have a tough time proving to management that more resources are needed.  Well, if you're tracking your allocations within your project and your capturing the actual time spent on tasks, you will be able to prove when you're over-allocated.

Hopefully, you've seen my previous postings on establishing and using metrics within the SDLC process.  If so, you know that I'm a big believer in measuring what is valuable to your organization.  If you haven't been producing standard metrics from your Project Plan up to this point, now is the time to start.  You should be able to track progress against your milestones and be able to report that up to the Project Sponsor.  You should be able to compare current milestone dates to baselined dates and report slippage up to the Project Sponsor.  You should be able to identify when people are falling behind and, hopefully, step in sooner to mitigate the overage.

Have you standardized your Project Plans and are you using the Project Plan to drive activity within the overall SDLC?

Tags: SDLC, Project Management, Timeline, Tasks, Milestones, Budget, Template, Management, Projects

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