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

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

Metrics Do Make The World Go Round!

If you can't measure it, you can't fix it.  To be more specific, you need to be able to recognize those things that are slowing you down, interrupting the flow, introducing defects, raising costs and frustrating your team members.

Some things you can figure out just walking around, talking to your team and taking a look at what is happening on a daily basis:

1. Seeing that your technical teams are getting interrupted regularly and don't have time to concentrate on their assigned work.
2. Seeing that your developers are the only ones testing their own code before moving it into production.
3. Seeing that the project team is doing a lot of rework because nobody is willing to make a final decision.

At some point though, you'll have reached up and plucked all the low hanging fruit off of the tree.  Then comes the tough part.

Our processes can't remain static.  We need to look for ways to reduce the timeframes necessary to deliver products to production, instill a zero defect mentality within our teams, improve communication between teams, reduce the amount of time needed to regression test our code, and focus more of our time validating the new functionality.

This is where metrics come in to play.  You need to begin to identify the key data points within your cycle that you can use to measure/monitor.  Then you need to build in ways to capture those data points.

1. How long does it take to move through any one phase of your lifecycle?
2. How many elements require rework at any stage of the process?
3. How many times do you have to backup in the lifecycle?
4. How many defects, and what kind of defects, are found within the various testing - unit, integration, regression, parallel, or UATs?
5. How much of your code has valid tests that you can prove exercise the code?
6. How many defects are found after the code is moved in to production?
7. How much time is wasted with the project in non-productive time as you wait for various teams to be available?
8. How much of your teams time is being wasted on unproductive activity - non-project meetings, administrative activity, or unapproved development activity.

Now, the fine line is defining and being able to record these data points without impacting activity within the overall lifecycle.  What systems do you have in place today that are used within the lifecycle and can you augment these systems to capture the data points that you have identified and be able to automatee the analysis of the data.  There will be some level of manual analysis - but, I would recommend automating as much of this activity as possible.

How can you make the argument that you need to add new resources if you can't prove that your resources are saturated with approved project activity?  How can you make decisions on your test processes if you don't know where your tests are failing?  How can you hold your development team accountable if you don't know where their spending their time and how many errors are getting past them and in to the QA environment, or worse yet, production?

I'm not advocating that you immediately go out and measure create metrics across the lifecycle.  I do challenge you to think through your lifecycle and begin to identify the parts of the lifecycle that need adjusting and then think about the metrics that could be catured that would help you make decisions.  If you are totally comfortable with your entire process - then I would gather feedback from your peers throughout the organization, asking them what is and is not working, and use that information to guide you on where improvements could be made to your lifecycle.

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

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

Sometimes, You Do Need To Break The Rules!

Well, it is all about the process, except when you need to forget about the process!

Quite the title … and an accurate description of what we all deal with on a daily basis.  There are some projects that come through the pipeline that don’t qualify for the full pomp and circumstance of the defined Software Development Lifecycle (SDLC).  Sometimes it is a low risk project, sometimes it is a project with a predefined date mandated by a client or a partner, and sometimes its just that everyone agrees what needs to be done and you just need to get it done.  Whatever the reason, we all have those projects that run through our departments with minimal oversight.

So, when this is happening to you, what is your reaction?  Many organizations just let it happen. Hey, the boss wants it, just get it done.  Right?  Nope, I’m here to argue for a process for the instances when someone says the process is getting in the way.

Ultimately, this is happening because someone in the organization feels that the formal process slows things down and that the need the team to be more nimble.  And, my response, yes.  If you make every project go through every phase and produce every artifact of your lifecycle - then it is going to slow things down.  The caveat - if you only look at it from the perspective of the first time through the cycle.  Typically, if you have a complex project and you begin skipping artifacts or lifecycle phases, you end up missing requirements, developing the wrong features, spending more time in testing or delivering a product into production with a higher level of defects.  Notice that I said, “complex project”.  The problem is that not every project that runs through your pipeline is complex.

So, what’s a team to do?  Strip down your process - identify the complexity and risk of the project at the beginning,  and make decisions on what can and cannot be left out during the various phases of the lifecycle.  Do you really need a discovery phase with it’s associated documents, or can you skip right to the requirements phase?  Do you need to create both a high level project design and a detail design, or can you skip the high level and just do the detail design?  Do you need to formally go through all of the decision gates, or can you just do the final gate prior to the project moving into the production environment?  Do you need to run in parallel, or will a regression test be good enough? Every project is different and for some projects you can simplify the process and reduce the churn and labor associated with the full SDLC.

I’m a huge proponent of creating a formalized SDLC process within an organization.  This can be waterfall, Agile, RAD or any other methodology that works for your organization.  That said, we can’t let the process get in the way of every project.  It’s not needed.  In fact, you may need to run waterfall on some of your projects and Agile on other projects.  I’m not here to tell you which process to use - just that you need a process and you need to be flexible in the implementation of that process within the organization.

I’ve had the fortune of creating the SDLC process for various organizations throughout my career. Small dedicated development shops, to larger teams spread out across multiple locations.  I’ve faced the same issues in every organization that I’ve been associated with.  At some point, someone higher up the food chain is going to make a commitment that you have to keep that will force you to break your process. Maybe that person will actually be you!  Will you just let it happen, or will you step back and optimize the SDLC for the specific request.  Once you do it, you will begin to find ways to make this happen on other projects moving thru the lifecycle.  This will show your team and management that you’re interested in making changes that improve the productivity and accelerate the development pipeline.

At one of my previous positions - I was constantly used as the example of someone who broke the rules.  Not in a bad way, but in a way that showed I was willing to change the status quo and find a different path to get things done.

What are you doing in your organization to streamline those projects that don’t need all the pomp and circumstance of your formal SDLC?

Tags: #SDLC #softwaredevelopment #lifecycle  #applicationdevelopment #programming

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

It's a Mixed Bag - Book Recommendations to Labor Issues

This entry is going to be something a little different - several topics that I want to cover and now seems like a great time to throw the topics out for discussion.  Hopefully, you will find at least a couple of words of wisdom along the way..

Topic number 1: Pet peeve of mine: what’s with the passive-aggressive responses and actions.  It is tiring, unproductive, destroys morale and ultimately a career.  It wears me out to sit in meetings with these types of individuals and to see them nod their heads in agreement, give verbal assurances that they are on board - only to walk out the door and spread dissension and drive a team and project into the ground.  If you want to know why people leave an organization, it’s because they work for individuals that aren’t passionate about what it is they do and disrupt the organization more than they help drive the organization.  I’ve seen this play out in several organizations and it always ends up the same way.  Good people leave before action is finally taken to put a stop to the individual that is causing the mess in the first place.

Topic number 2: “First, Break All the Rules: What the World's Greatest Managers Do Differently”. This is a book that I originally read at least 10 years ago.  It was part of a mentor program that I was taking part in.  I didn’t realize it at the time, but as I have reread the book several times it has helped change the way that I look at my team members - how I recruit new team members and how I manage my teams.  In a nutshell, it challenges you to break the age old paradigm where you end up spending time with individuals that are not performing well, to stop spending time on trying to get people to change and to instead find the unique talents of the individuals on your team and focus those talents so that the person can succeed.  Yes, you can train individuals around the edges of their talents, but fundamentally, you’re not going to teach someone who hates working with numbers to love working with numbers.  What you need to do is identify the talents, skills and knowledge and ensure that they align with the role that you have that individual playing, then clearly identify the outcome that you are looking for and let the person run with it.  Here is the part that I am challenged on - the book argues for less formalized processes and procedures.  That is where I diverge from the arguments made by the author - in my line of business, standardization and controls are needed.  I would highly recommend this book to anyone that is responsible for leading a team of individuals.

Topic number 3: “The Five Dysfunctions of a Team: A Leadership Fable”.  When I was hired into my current position, this was the first book that I was asked to read by the CIO of our organization. This book is a fast read, the story focuses on traits within a team that can lead to a complete breakdown. The characters feel real and the storyline is plausible.  Our CIO references this book often and have found myself reading this book over and over.  Each time I read it, I find a new nugget that I can take back and use in the way that I interact with people.  The author creates a story where a company is on the verge of folding, a new leader is brought in to the organization and must enact a turnaround.  I won’t go into the blow by blow of how the story unfolds, but the reader is given great insight in how to create an environment where teams can succeed together.  Make no mistake - the lessons from this book are not easy to put into play within a team, but ultimately they will make the team more effective and more accountable.

Topic number 4: Guestworkers in the STEM labor market.  Today I read the results of a study that turned the well known argument for additional H1B’s on it’s head.  I freely admit that I have used talent via the H1B program, and have found it to be useful when I have not been able to find local candidates to fill software engineering positions.  Here is a quick link to a summary of the study: “Guestworkers in the high-skill U.S. labor market”.  There are a lot of details within the summary, but essentially the study argues that the US based higher education system is graduating enough technical talent to fill the job openings within the Information Technology (IT) fields.  Showing that we are graduating two students for every available job opening.  Annually, the number of guest workers entering the US labor force is equal to ⅓ to ½ of new job holders within the IT field.  I think the broader question is how do we find students willing to work where the IT jobs are located.  While not addressed within the study, I can speak from a well earned history, that it is difficult to convince college graduates to stay in the mid-west - many new college graduates want to go to the coasts (Silicon Valley, New York or Seattle).

Topic number 5: Have you hired a college graduate lately?  Too many times, I’ve been asked to make sure that the next person hired has experience - we can’t afford to hire a newby into the organization.  I not only hear it within my own teams, but I hear it when I spend time with my peers.  I understand the need to make this argument for some openings, but not for every opening that comes along.  Let’s step back a second and look at what we are doing.  How many times have you gone out to find someone with experience, just to be frustrated with how long it takes them to come up to speed and be productive within your organization.  The more complex your environment, the longer the learning curve.  You’re going to have that learning curve, with and without experience - it’s a fact.  However, you could look for a recent graduate - someone who is passionate about digging in and figuring it out.  Some with a fresh perspective on the job.  Someone who is going to ask why and keep digging until they find the answer.  Graduates need an opportunity to get hired and ultimately may become more loyal to the team and the organization.  How long does it take you to find and hire a candidate with experience.  My bet is that it takes you months.  If you were looking at entry level candidates you could have the position filled within 1-3 weeks.  Give a graduate a break - hire them!

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