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

Implementations - When Things Go Bump In The Night!

Sometimes bad things happen.  The question - how fast are you able to respond and put things back on track?

Technical teams need to plan and test their ability to rollback changes that are negatively impacting users.  This needs to be a formal part of your process - sometimes that means falling forward, fixing the broken functionality in production; sometimes that means falling back and reverting to a known state where the application was functioning properly.

Let's be honest - none of us are perfect all of the time.  Occasionally, we are going to miss something and move code into the production environment that ends up breaking things and making life miserable for the folks actually using the application.  

What have you done to prepare for this moment?

1. Does your implementation plan include steps to proactively monitor the system as changes are moved into production?
2. Does your implementation plan allow time for you to look at patterns of application activity to validate that you are not seeing patterns that would indicate that something is broken within the application?
3. Does your implementation plan include validation steps to ensure that the application is acting accordingly and that the new/changed functionality is working?
4. Does your implementation plan identify risk points and fallback strategies?
5. Have you tested your implementation plan?
6. Have you tested your fallback plan?

Every environment is different - but we mostly face the same types of challenges.  Breaking things that users expect to work is not what we want to do, but occasionally, it happens!

Yes, planning your implementations takes time.  Yes, planning validation steps and inserting them into the overall implementation plan takes additional time.  Yes, testing your implementation plan chews up more time.   And, yes, testing your fallback plan takes even more time.  That all being true, failing to do any of this means that your operating by the seat of your pants and your recovery time when things go bad will hurt you worse.

1. When your application fails - the reputation with your customers takes a hit.
2. The longer the outage increases the risk that your customers will walk away from you and begin to use a competing application?
3. Will an outage impact your revenue stream?

Now, all that said, sometimes even with all of the best planning, you're going to get caught.  It's bad enough when it's a web based application/service where you can make immediate changes or perform and immediate rollback.  However, what if it's software that you're sending out to customers - that they install on their systems?  How do you think Microsoft feels when they send out one of their regular patches only to find out that it causes the blue screen of death.  This can affect millions of computers around the globe.

Not to hit Microsoft too hard - but, in April they released a patch to Windows 8.1 that was required before any other updates could be applied.  This impacted retail customers as well as corporate customers and was not fixed until early May.  I'm sure that they ran their standard quality processes against the code prior to the initial release in April - but something obviously got by the testers, and it wasn't a minor issue.  It took time for Microsoft to hit the reset button, but in the meantime their customers were in an uproar.  

I'm going to walk softly here because as a developer it could happen to me or the teams that I lead.  I'm not trying to single out Microsoft - anyone that writes software has had to recover from a misstep when loading code into production or sending out a new release.  What I'm advocating for is that you implement solid processes that minimize the risk to your customers, your team and your organization.

What are you doing to mitigate the risk of an implementation/software release going bad?

Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making; Project Management; SDLC; Lifecycle;

For more information on David L. Collison: LinkedIn Profile

Management - Leading, Coaching, Mentoring!

Well, I think it's time to switch up topics again.  With this posting, I'd like to change lanes and look at the human aspect of management.  As Leaders and Managers within the technology field, we need to be able to shift from the technical aspects of our jobs and deal with the individual team members at the drop of a hat.

Whether we realize it or not, we swing between different roles during the day as we move between issues and projects.  Depending on what is happening, we need to get in to the technical details of a specific sub-system or project; an hour later we may need to display our ability to drive to a decision; in another moment we may need to handle a disagreement or communication issue between two members of our team; or, we may need to mentor or coach an employee to continue their growth as they prepare for new opportunities.  Day to day, our bearings shift as we navigate between the various events that surface, that want to take us off task.

As I look back on my career - and, yes, it has been an interesting ride with paths yet to be explored - I think the toughest shift I've made was when I went from being the programmer pounding out code to a manager no longer responsible for creating the code.  I've touched on this subject before, so I won't belabor the issue.  That said, hitting that particular brick wall made me assess what my role was, what was important for me to focus on and what I needed to "give up".  My boss at the time let it happen and I give him a lot of credit for giving me the space to fail and then sitting me down and forcing me to understand my role.

As my boss pointed out to me at the time - I was there not to be the technical expert, but to mentor and guide the people on my team; to remove the roadblocks and ensure that my people knew what it was they were supposed to do and ensure that they were provided the proper resources to get it done.  I was there to keep them focused and to deliver results.  Along the way, I learned that there were limits to what I could do and that I would never be able to provide all of the resources that my teams wanted.  Nor could I feasibly address every project that was requested - it was up to me to find the balance between what was requested and what the company and the available resources could provide.

Now, all that said, I earned some bruises along the way.  There were times as a young manager, I didn't necessarily treat people the way that they should have been treated - sometimes my driver personality got the better of me and I ended up doing or saying something that wasn't as well thought out as it should have been.  In those moments, I was lucky enough to have a boss that continued to coach me, to teach me how to smooth the edges.  These learning experiences through several mentors have shaped me in to the role that I play today.  Do I still sometimes let the driver in me get the better part of me - yep, but it happens a lot less than it used to these days.

People that I respected took the time to invest in me.  They knew when I was at a point that I needed a stretch goal; they knew when it was time to take me out of my comfort zone; they gave me room to make mistakes and fail; they let me come and ask questions; they let me make a difference.  And when needed, they pulled me back from the abyss.  Even today, I am mentored by someone that I respect and that I feel is pushing me and preparing me for that next step in my career.

Not every boss I've ever had was a mentor - I've had my share of clunkers along the way.  Case in point, the boss that flew in to town right after my department had been moved under his to inform me, and I quote, "I don't know what it is you do, I don't want to know what it is you do, if you need something, tell me who I need to talk to and what I need to say".  Yikes!  Or, there was the owner of a company that I worked for that felt it was appropriate to verbally abuse everyone on her staff - the rush for the door was quick once it started and to this day I'm sure she never understood the message.

Somewhere along the way, I learned that I could also be a mentor.  Not everyone wants a mentor, but to those that do, I attempt to be available.  Sometimes, I identify someone who I think has the potential to act in a different role and I initiate the conversation.  Sometimes individuals ask if I would be interested in giving them guidance.  Sometimes these people report to me or within my organization.  Sometimes these people don't even work for the same company I work for.  However, it's my turn to give something back.

What are you giving back to your teams?  Who is it that your mentoring so that they can take that next step?

Tags: Leadership, Mentoring, Management, Lifecycle, Software Development

For more information on David L. Collison: 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

Being a Project Manager - Part II

So, the last time we all gathered, I discussed the Project Manager.  We spent some time exploring the responsibilities of the Project Manager and dove in to things like planning, budget management, time management, resource management, risk identification and mitigation, quality, documentation and team leadership.  These traits and activities are important, but they are only one-half of the full equation.  If you look closely at the previous posting and the items just mentioned, you'll see that they point down or flow horizontally through the team and the organization to promote activity that will allow the project to succeed.

Managing down and across the organization is important.  However, there is one piece of the puzzle that I didn't mention.  And, those of you that have been in the business for a while, already know what's coming.  What was left unmentioned and what I'd like to cover in today's discussion is the fact that effective and successful Project Managers must learn to manage up!  Manage up?  Shouldn't the Project Manager be relying on senior leaders in the organization to act as their escalation point and provide cover when needed.  Unfortunately, the answer is more subtle than that - it is more of a yes and no depending on the situation. 

Any organization is full of politics.  Some organizations manage it better than others, but in any organization there is an underlying game that gets played.  And the Project Manager is left to ensure that the project gets completed within the constraints originally identified while trying to keep all the players happy.

1. First up in batting order is the Project Sponsor.  This is the player that went to bat to champion the project.  They fought for the priority, the budget and the resources to make it happen.  It's the Project Managers job to make sure that the sponsor is kept in the loop, has a proper understanding of what is and isn't in scope and how well the project is aligned to the overall timeline, budget and resource requirements.
2. Moving through the batting order we then go through the Senior Management Team.  Each of these individuals represent competing interests and will lobby to see project changes that benefit their slice of the organization.  Once scope is approved, it's the Project Managers job to maintain order and limit scope creep.  While there is always room for minor adjustments in the overall scope and project activity - it's the Project Mangers job to ensure that these changes do not impact the budget, timeline or resources.  Additionally, if the Project Manager feels the change is justified, then they must keep the Project Sponsor in the loop.
3. Next up is the Project Manager's boss and the Project Management Office.  They've set the constraints around all project activity and they are the keepers of the approved SDLC process.  They have the keys to the overall portfolio and the Project Manager must be sure to align project activity with all of the other company initiatives.
4. Then there are the Resource Managers.  The Project Manager has assembled a short term tactical team to execute against the overall tasks and activity of the project.  These resources don't belong to the Project Manager, they've been borrowed.  Their Resource Manager is going to want to pull them back at times to work critical production problems, fill in for a resource that is suddenly gone or for any number of other reasons.  The Project Manager will need to manage these diversions.

As you can see, life just got a whole lot more complicated.  In a perfect world, the Project Manager would never have to worry about things going wrong.  Unfortunately, for any project of any size, things will go wrong, contingencies will need to be identified and keeping everyone in the loop will become a necessity.

You have this particular job at this particular time due to the Project Sponsor.  They've placed some portion of the success of their career on the project that is winding it's way through the organization.  If they weren't passionate about the results of the project they would not have lobbied to make it happen.  As the Project Manager, you may not fully understand the full reasoning of why it is important to the Project Sponsor - but trust me, it is.  As the Project Manager, it's your job to keep this individual fully informed of  what is happening within the overall project.  That's not saying you have to update them on every decision, every risk that gets identified or small shifts in resources.  That's what they expect you, as Project Manager, to do - it's your job!  What they do want to be made aware of are the big things - and each sponsor will have their own definition of what the "big thing" is.  Most times you can focus on the following:

1. Identifying others in the organization that are attempting to change the approved scope of the project - thereby causing ripples throughout the project that will potentially change the product that is delivered or impact the budget, timeline or resources involved in the project.
2. Identifying when 3rd parties are not meeting the expectations identified at the beginning of the project or as documented when the contracts were signed and they engaged on the project.  And expectations means that they are either performing or not performing in a way that could impact the quality of the delivery, the budget, timeline or resources involved in the project.
3. Identifying items that surface throughout the project that insert risk in to the overall activity and could cause the project to derail and go over-budget, increase the time necessary to deliver the product or alter the number of resources needed to complete the identified activity and tasks associated with the project.  It's the Project Managers job to mitigate risk - and the Project Sponsor will expect that activity to be done, however, they will want to know when these risks or issues are identified and what the team is doing to resolve the risk.
4. Identifying when production issues or shifting priorities impact the overall project.  These are issues outside the control of the Project Manager, but the Project Manager better be communicating these up and across the organization.
5. Identifying what issues need to be escalated and then managing those items so that they do not impede the progress of the project team.

The Project Manager should meet with the Project Sponsor early in the overall project to establish the ground rules.  What are the specific items that the Project Sponsor is worried about?  What does the Project Sponsor want to see in project updates?  How does the Project Sponsor want issues escalated?  How often does the Project Sponsor want to be updated on the overall progress?  How does the Project Sponsor want to see items that need to be escalated?  As issues arise in the project - what are the give points?  Is there a commitment date where the product must be delivered by a specific date and that means more resources need to be pulled in when needed?

The difference between a good Project Manager and a great Project Manager is the ability to understand that it's not just managing activity within the Project Team - but managing across and up through the organization to ensure that the project can stay on track and be a success.

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

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

Running Your Project Team Meetings

How many of us are running effective project meetings?  I know this sounds trivial, but I’m serious.  Think about how long your project meetings are and what you’re accomplishing – the decisions you’re making, the issues you’re addressing and the mitigation plans that are being discussed.  Does the value of what you’re producing in these meetings exceed the combined hourly rate of the participants in the meeting?

First off – what’s the purpose of your meetings?  Are you meeting to regurgitate status information that everyone knows?  Are you meeting to capture the details of actual work activity?  If so, then you’re meeting for the wrong reasons.  In my humble opinion, standard status information should be collected and discussed prior to the meeting – through informal walkabouts, emails, instant messaging and/or phone calls.  If you’re using your status meeting to gather this information – you’re boring the participants of the meeting.  What you should be focused on are the exceptions:

1. What were you planning/hoping to accomplish that you couldn’t accomplish?  Why?
2. What roadblocks have you encountered?  Are there options for a mitigation plan?
3. Based on what you know now, are there any new risks that need to be identified?
4. Based on what you know now, are there any obstacles to hitting our key milestone dates?  If so, are there options that would allow us to still hit the milestone dates?

Hopefully, as the Project Manager, you’ve already identified the above items through your informal meetings.  What you really need the Team Meeting for is to ensure that this information is being shared and communicated with the larger team.  And, most importantly, the information should be evaluated by the entire team to ensure that the best mitigation plans are formulated and executed.

Nobody wants to sit in a meeting for an hour to go around the room and hear that “everything is fine”.  It’s your job as Project Manager to dig into these statements and validate, “Hey, that’s nice to hear that everything is fine and on-track.  Are you finding any issues in the implementation that differ with the Project Level Designs or Details Designs?  Do we need to clarify any of the information that was passed in to the Development Team on the functionality your developing?”  Often, that will open doors for individual project members to highlight issues and provide you with feedback that can be used by the entire team.  Most people aren’t comfortable bringing up topics that they feel are negative in a group setting – it’s up to you as Project Manager to dig deeper and pull that information out.  Building those relationships in the informal meetings will go a long way towards getting people to open up in the Team Meetings.

I’ve also had several Project Managers tell me that they meet because best practices say that they should meet as a team once a week or bi-weekly.  Some Project Managers have told me that meet 2-3 times every week – to stay on top of things.  Seriously – a full team meeting 2-3 times a week?  That seems like overkill – there may be specific points within a very complex project where that is the case, but, by and large, if you’re needing that meeting frequency on every project you run, something is probably wrong.

I understand daily standups – these are quick 15 minute meetings with teams or sub-teams involved in the project.  Most times these are structured around covering subjects that promote team focus – what was accomplished during the previous day, what is planned to be accomplished today and what is causing delays.  The team can then collectively address issues that are causing delays.  I view these as separate from the full Project Team Meeting.  The full Project Team Meeting crosses organizational silos – involving development, infrastructure, quality assurance, architects, finance, marketing, sales, operational teams and others throughout the organization.  The daily standup meetings are more team focused – and the information discussed more granular.

Back to the issue at hand – how often you’re holding Project Team Meetings.  I actually don’t mind, in fact I encourage, Project Managers to schedule weekly Project Team Meetings.  The difference – I also tell them to cancel the meeting if there isn’t enough value that will be derived from holding the meeting.

As the Project Manager, I expect them to know if there are issues through the informal contacts that they have with the project team.  If the project is at a state where things are relatively smooth and there are no outstanding issues where mitigation plans need to be developed or where there is not a milestone that is driving communication between teams – then don’t meet!  It’s that simple.  The Project Manager should be empowered to understand the focus and purpose of the larger Project Team Meeting and make decisions on when it is useful to hold a meeting or through informal communication with the overall team – cancel a meeting.

What’s the purpose of your meetings and are you driving enough value to justify the cost?

Tags: SDLC, Lifecycle, Project Management, Project, Management, Meetings, Status, Team, Development

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

Security Matters – And It’s Not Going To Get Any Better …

If you have any type of a system interface that is exposed to the internet, then you have a potential problem.  In case you haven’t heard, there’s a war going on and you had better be making sure that your defenses are in place and being kept up to date.

What used to be the realm of script kiddies playing with ways to hack in to a system for fun has grown in to a full blown international business with hackers stealing real money, downloading corporate data, or turning your systems in to a swarm of botnets that can be used to hack in to other systems across the world.  The landscape isn’t getting any prettier with governments now openly accusing each other of state sponsored hacking.

Today, one of the most sought after positions is the role of a security architect/analyst.  These are the white hat hackers that work to keep a company’s systems and applications safe.  In today’s world, I wouldn’t ever make the claim that they can fully protect you, but, if they’re doing their jobs, they’ll dramatically lower the chances of your systems being successfully attacked.

And, these days, you have to be just as concerned about internal hacks as you do about the potential for someone outside the company to perform the hack.  If you are hacked, the chances are far better that you’ll be hacked by some outside party, but that doesn’t remove the threat of a disgruntled employee leaving a back door open so that they can clean you out down the road.  According to the 2012 Verizon Data Breach Investigations Report, they found the following:

• 98% of the data breaches were initiated from external agents
• 4% involved internal employees
• 58% of all data theft instances were initiated by activist groups

See the following link to read the entire report: 2012 Verizon Data Breach Investigations Report

The report is sobering to say the least.  The most damning piece of data from the report: 79% of all attacks were targets of opportunity.  Meaning that the company impacted left the doors open by not taking proper precautions and securing their systems and applications.

I’m not going to use this space to regurgitate the findings from Verizon’s report.  What I do want to do is spend a few minutes discussing the relevant point in time to talk about security.

That would be NOW!

Ok, let’s break it down from the beginning.  Within whatever methodology you are using to run your projects and manage your SDLC – you need to incorporate security up front in the process.  Within each project you need to be aware of the security risks and take appropriate action.

1. What are the risks associated with the project – hardware, software, interfaces, data, etc?
2. What is the likelihood of each risk occurring?
3. What is the mitigation plan to remediate the risk?

These questions need to be asked up front and security needs to be built in to the requirements/stories that the team will use to build and test the solution.  That’s right, you not only need to build the requirements upfront, you need to test them just like any other requirement.  Moreover, there are industry best practices to follow at both the physical infrastructure/data center level and the application level:

Data Center Best Practices

1. SAS70 Data Center Security
2. Best Practices for Data Center Security
3. 19 Ways to Build Physical Security into a Data Center

Application Security Best Practices

1. OWASP Web Application Security
2. Microsoft Security Development Lifecycle
3. ISC2 Ten Best Practices for Secure Software Development

It doesn’t matter how large or small of an organization you work for, if you are not building security in upfront, you are asking to be hacked.  And, yes, that may mean breaking the current processes you use to manage and build your infrastructure, as well as your software development lifecycle.

Several years ago, Microsoft was the recognized pariah in the security world.  There systems were like Swiss cheese and attacks on the MS-Windows operating system and MS-Applications were a daily occurrence.  Finally, in January, 2002, Bill Gates sent an email to every employee of Microsoft laying out the strategy to develop security within their products.  Bill named it Trustworthy Computing – which over time morphed in to the Microsoft Security Development Lifecycle.  When it comes to developing secure operating systems and applications, Microsoft is now ranked among the best in the industry.  Bill Gates was famous for being able to pivot the Microsoft machine and finding a way to successfully change the direction and trajectory of the company.

So, what are you doing to ensure the security of the systems that you are putting in place?

Tags: SDLC, Software Development, Lifecycle, Process, Application Development, Security, Web Development, Application Security

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

Metrics - How I Use Today

Metrics are a funny thing - what works for one team may not work for another team.  In practice, I have always found that I need to adjust the metrics that I track based on the organization.  I find it humorous when some vendor walks in the door and tells me that if I just revamp my process to use their custom SDLC solution and manage by their key indicators that all of my problems will be solved.  Dream on!  If I’ve learned one thing, it is the fact that I must be sensitive to the unique culture of the organization and create a process and metrics that work within the overall organization.

So, that said, I’m going to walk through some of the metrics and processes that my teams currently utilize and how these get used to strengthen the overall lifecycle.  You may find some of this useful, or you may decide that the whole thing is nonsense.  That’s up to you - what I can say is it works for the teams that I manage and is trusted by the management team to give insight into our overall portfolio.  This is still somewhat high level, but it will give you the general flavor of the things that I consider important.

One of the first things that I did walking in the door was to have the entire development team begin tracking what time was being spent on what activity.  There were multiple reasons for initiating this type of tracking:

1. It allowed each individual developer and their manager to identify where they were spending their time.  It also initiated conversations on why people were spending time on certain activities.  Over a period of several months, we collectively managed to increase time spent on corporate approved projects from 35% of the overall time to 65% of the overall time.  We continue to look at this metric to ensure that people are spending time on approved project activity.
2. It allows me to understand how many hours people are working and to look at when I need to increase our headcount.  Over the last six years, I have used this data, along with other metrics information, to initiate the discussion on headcount increases and win those discussions.

Time tracking allows me to identify several metric points that provide insight into our overall lifecycle, as well as down to individual resource management:

1. Overall time spent on a given project across all resources.  How did it compare to our baseline estimates?
2. Time spent on activities within the project vs the baseline projections.
3. Are our estimates accurate?
4. Did we identify development activity that was missed during the design stages?
5. Individual time analysis - approved project activity vs production maintenance vs defect management vs administrative overhead.
6. Team analysis - approved project activity vs production maintenance vs defect management vs administrative overhead.

This has proven so successful within my team, that the entire IT Department now tracks their time and all individuals within the Business Teams track their time against project activity.

While time trackings helps at an individual project level and at a resource level - it is responsive and does not allow you to project out over a period of time.  For that you need a view into your entire portfolio.  To that end, we have a Portfolio Plan that is reviewed on a weekly basis by myself and my peers across the organization.  We do this to identify bottlenecks in the process, find ways to breakdown barriers and push the projects forward.  Here are the key metrics that we review:

1. Each project within our Portfolio Plan is broken into 6 distinct phases - Discovery, Requirements, Technical Design, Development, Testing and Launch.
2. Each phase has two key dates - Start and Finish.
3. Each phase has resource allocations assigned for each team.
4. At the end of each phase we adjust our timelines and allocations for the following phases based on what we’ve learned to date within the project.
5. Each project in the Portfolio Plan is tied to the associated “real” project housed in our MS-Project Server.
6. Each “real” project has standard milestones that identify the initiation of each phase and the completion of each phase.
7. Each day - routines are run that allow us to provide analysis of the Portfolio Plan vs what is happening within the “real” projects.
8. Periodically, I go in to relevel the entire Portfolio Plan to ensure that we are not over-allocating any one team and that we have enough work moving through the pipeline.

Why do we do this?  Simple, it helps us control the activity in the organization today and allows us to review the allocations of the various teams and ensure that we are levelling project activity over a period of time.  Most importantly, it forces us to prioritize what is moving through the pipeline.

1. I can tell when activity within any phase is going to be completed ahead of schedule, on schedule or is behind schedule.
2. I can use the above information to tell me when I need to reallocate resources so that I can hit internal target dates for critical projects.
3. I can use this information during budgeting to review with Senior Management and discuss our pipeline to see if they are ok with the volume of activity we are managing or if we need to increase our pipeline.
4. I can use this information to hold individuals and teams accountable.
5. I can project out when we will be trying to force through too much activity within the overall pipeline and use that information to initiate conversations about the priority of project activity.
6. I can use this information in conjunction with the time tracking data to identify when additional resources might be useful.

So, removing ourselves from the project level and going down to where the rubber meets the road, let’s look at some of the metrics that we are tracking within the development team as it relates to coding:

1. We have begun implementing nightly builds/nightly regression tests across all of the development teams.  Some teams are further along in the process than others, but all are moving towards the same overall goals.
2. Jenkins is used as the tool that automates all builds for all packages across all environments.
3. Jenkins is also used to gather results from the build process and the regression test process.
4. Jenkins is used to distribute emails to team members and management members identifying the results of the build/regression test process.  Developers are then responsible for going in and fixing the issues that have been identified.
5. Sonar is a tool that allows us to view the results of the build/test processes in a web application - broken out by each application.
1. Line Coverage - how much of our code has been validated with test cases
2. Unit Test Success - how many of our tests completed successfully, how many failed.
3. Violation of Rules Compliance - how many instances there are where code is not conforming to coding rules - both those identified as industry best practices and those that we have defined internally
4. Severity off the violation.
5. Code Reviews - I can tell if the code has gone through our review process.
6. Other metrics are provided - but I don’t consider them as useful as those identified above.

All of the above gives me insight into the overall confidence of the package before we move to production.  I can review this anytime I want and see our progress in knocking down the number of bugs being found by our standard unit and regression tests.  I can see if we are improving the overall amount of code that is covered by our tests.  I can see if we are reducing the overall number of violations that we are finding within any given application.

Moving in to the formal test cycle, I then begin to track a different set of metrics:

1. How many defects were found by QA that were not identified by the Development Team through unit, integration or regression testing?
2. How many new package builds occur before QA has a clean package ready for production?

Each week we notify the entire management team of changes impacting the 6 phases of our project lifecycle.  Those projects where dates have shifted for any given phase are identified along with explanations - a miss by the team, extended due to resource constraints, extended because we missed something, reduced because it was easier than we anticipated.  Whatever the reason, it is noted and everyone has visibility.

On a bi-monthly basis we meet with Senior Management to discuss the overall portfolio.  The slide in timelines - positive and negative - that we are seeing across all projects.  Projects impacted by levelling activities.  Reviewing the priority of projects so that we understand where to focus time when the pipeline is packed full.  Understanding shifts in strategy that we need to accommodate within the overall pipeline.

At the end of our projects, we provide summary information to our Senior Management Team that compare the total number of hours spent within the various teams vs the baseline estimates.  We report on the total $ expenses vs the baselined estimates.

Again, this is somewhat high level, but it gives you a flavor for some of the things that I consider useful as my teams move projects through the lifecycle.  Most of this was accomplished using tools we already had in place - but that we weren’t taking full advantage of:

• MS-Project
• MS-Project Server
• PWA
• Reporting Analytics
• Jenkins (Build / Test Automation)
• Sonar (Consolidated Build Reporting)

Yes, there are other metrics that we track and discuss.  This has all been done with an eye on improving individual and team productivity, reducing the number of errors moving through development and into QA (ultimately into production), holding individuals and teams accountable and ensuring that we are prioritizing activity within the organization to align with the overall strategy communicated from Senior Management.  I’m focused on those metrics that can provide significant results for the organization.  I’m not interested in adding metrics to produce pretty charts.

None of these metrics are full-proof and each must be taken at face value.  Sometimes the metrics lie and that’s where it is the job of us as individuals to interpret and validate the results.

Tags: SDLC, Software Development, Metrics, Lifecycle, Software, Application Development, Project Office

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