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

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

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

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

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

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

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

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

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

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

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

Don’t Be Afraid … Change!

Over the last several years, my teams have made significant changes to our project management, development, testing and implementation processes and paradigms. We’ve had some bumps along the way and in no way do I consider this evolution over. I will continue to challenge my team members to find a better way to build the mouse trap that drives our software development lifecycle.

Let’s look at some of the successes the teams have had introducing change into the organization:

1. Our project management process used to be split into separate and distinct teams: 1) project management for business and operational teams; 2) project management for technology teams. This has been consolidated into one project management team managing all project related activity across the organization. This has streamlined activity and improved communication across all teams involved in the process.
2. Our lifecycle was revamped as we consolidated the project management organization. During the revamp – we created RACI documentation that clearly outlined 1 owner for each key task/milestone within the overall project activity, along with those that would act in the roles of responsible, consultative and informed parties. This has provided clarity to who owns each activity and what the key tasks are that are included within every project.
3. Recently we made additional changes to the lifecycle – completely eliminating 1 phase and adjusting the tasks and milestones associated with both our scoping and design phases. This has allowed us to streamline the process and give clarity to when project activity actually starts within the organization.
4. We have challenged all of our team members to review the overall standard tasks/milestones within any given project, and challenge the project manager and sponsor to eliminate tasks and standard artifacts when it is justified and where there is minimal risk associated with utilizing an altered process.  This decision then is documented as part of the project and communicated to the team to ensure that down the road, people can review the effort and understand why certain documents or tasks might not have been done. This should allow us to be more nimble and find the best path for each project to take thru the organization.
5. A couple of years ago, it took up to 3 weeks to complete regression testing associated with key functionality within our application silos. This was a manual effort that typically was handled by multiple individuals. The teams have worked hard to automate the regression tests associated with these applications. Today, the execution of these tests can be done in less than 17 hrs. The labor savings moving forward will more than pay for this effort. This also allows us to provide quicker feedback to the development teams and ensures that our regression testing is more consistent across all projects.
6. Recently, the teams also completed the resurrection of standardized test data to be used across our test and development environments. This will be further enhanced as our automated tests are enhanced to create/modify/cleanse and reset data needed for a given test. This will reduce the time spent creating test data for each project and will ensure downstream processes/applications have the data that is needed to execute their regression tests.
7. Over the last several years, our implementation plans have seen significant improvement. Our business demands that our systems be available 24x7x365. When you want to buy a tank of gas at 3AM or 3PM, you want the transaction to go through so that you can continue on your way. You would not find it acceptable for us to deny the transaction because we are updating our systems.  Our implementation processes have been templated and include all implementation activity, across all application and infrastructure silos, commands, scripts, validation and fallback steps in the order they will be executed.  Recently, our external auditors informed me that our implementation plans are among the best that they have ever reviewed. This has hardened our implementation activity – reducing the overall time needed to implement changes into our production environment, standardizing the validation activity during and after implementation activity has occurred and most importantly having fallback steps at the ready when any validation activity shows that there may be an issue.
8. Our development teams have changed their processes to include code reviews of all changes prior to those changes being introduced into our production environment. This is hardening our code base and reducing the risk of making changes within our production environment.
9. Our development teams have changed their processes to ensure that unit tests are created for all code being touched within a project.  These unit tests are then kept in a repository and used in future projects. This, again, has hardened our applications and reduced the overall number of bugs slipping through the process into our quality assurance testing or into our production environment.
10. Our development teams are now doing nightly builds – with reports going back to each team on build failures, unit test execution failures, code coverage and other statistics. This is giving immediate feedback to our development team and ensures that issues are addressed within 24 hours.

These are just some of the changes that have been implemented by the teams over the last several years. And we’re not done! Moving forward, we will move the regression testing into our nightly build process. We will be evaluating further changes to our development lifecycle to reduce the amount of time between idea generation and product introduction into our production environment. We will continue to improve upon our implantation planning. We will introduce key metrics across the development lifecycle. And where it makes sense, we will introduce Agile techniques into the development process.

I talk to college and high school students on a regular basis to discuss what it means to be in the technology field (specifically software development). The one constant that I tell students is that being in this field means you will constantly have to learn. They will learn new languages, they will drive change into the organization, they will experience multiple different development paradigms. All of this is good – it means the organization is alive, is learning and is adapting to its competition. 

Don’t settle for how it works today or with someone telling you, “well, that’s the way we’ve done it for decades!” Your job, no matter what role you play in the organization, is to find a better way, review your suggestion with those that can help implement, trial those changes and then roll them out across the team and the organization. Change is good – don’t settle for the status quo! 

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

A Little Help From My Friends!

I have been blessed in my life! I'm not a man of physical riches. Yes, I live comfortably and am able to provide for the needs and wants of my family. I grew up in a family that had a lot of love! Even though we live hours apart, we make time to get together at least twice a year - this has grown to include my nieces and nephews, their respective spouses and my great-nieces and nephews. Of course their are disagreements - but at the end of the day, we are family and I'm a better person because of my family.

My mom, dad and brothers and sisters were my first mentors. Being the youngest of six children, I did not lack direction from my elders growing up! While I may have fought against some of this, they taught me right from wrong, they taught me about responsibility, they provided my moral foundation, and, yes, they let me know when I was wrong!

Between high school and college, I had the good fortune to actually work in my dad's business. This was my first office job - having delivered papers and worked in fast food restaurants prior to taking on this role.  My dad showed a lot of patience with me as my attention to detail was not quite where it needed to be in those days. All that said, I learned a lot from working with my dad. His work ethic is impeccable, his fairness to others can not be challenged. My dad has always been my role model - in some ways I'm his clone (ask anyone who knows us), in other ways we are different.  I have never had the patience my father has, but he was the first one to call me out and I've continued to work at this my entire adult life.

Throughout my professional career, I've been fortunate to have people that cared enough to help lift me up and help me to learn things that I did not know. These mentors have made it possible for me to succeed!  They have made me learn lessons that I didn't necessarily know that I needed to learn or was to stubborn to recognize where I may have been making a mistake.

In fact, at one point, I was lucky enough to have 3 mentors at the same time: Beth Gritton, Jim Haddad and Art Christofferson - CIO, COO and CEO of McLeadUSA Publishing during the late 90's and early 00's.  To state that I learned from these individuals would be an understatement.  They never let me doubt that they trusted me, they were never afraid to let me make changes, they actively threw new challenges my way and gave me the support needed to succeed, even when I did make mistakes.

Beth took the time to show me the difference between being a manager and being a leader - lessons I still strive to understand today as I work with my teams. I have a strong tendency to react to what my team members are telling me about situations that need to be resolved and then inserting my view of the solution on them. Beth taught me to slow down and allow individuals to walk me through their issues as they see them, ask them questions and allow them to discover solutions, and support the direction that they want to take. That doesn't mean I sit back and let it all just happen. She also taught me how to understand when those decisions are material and when they are not. Letting people learn on projects and decisions that are not material and ensuring that the right support is in place when a decision is material and can impact the organization.

Beth was never afraid when I disagreed with her and would allow me to challenge her (note: if you're going to challenge your boss, do it behind closed doors and do it respectfully). When I felt I had a different way to tackle an issue, she would let me get my thoughts on the table, she would help poke holes in the solution I was presenting and more times than not, she would let me move forward with the recommendation.

Jim and Art were incredibly valuable as I learned from Beth. They both had open door policies and let me come in and 'chat' at any time. Both always expressed confidence in my abilities and let me know that they respected the skill-set that I brought to the organization. They never once cut a conversation off because they were 'too busy'. They would let me ask any question and they would always answer it - they never hid from the issue. In fact, in one instance I know I went to Jim with an issue that I did not feel I was capable of solving. Jim never hesitated, when I was done explaining the problem, he asked me how much it was going to cost to solve the problem and told me that he had faith that I would resolve it in a way that was a net positive for the organization.

Beth, Jim and Art allowed me to change the way that my teams worked within the organization and in how they supported the rest of the team. They held me accountable, but did so in a way where I was able to flourish, grow and become something greater than I imagined. I will forever be thankful for the experience to work and learn from these individuals - the ultimate mentors! 

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

Don’t Hide Behind the Process

Well, it’s been a while since I’ve discussed process issues.  Time to dig in and have some fun!

Most of you that have followed my previous posts know that I’m a process kind of guy!  I’ve introduced formal lifecycle management into several organizations.  The teams that I’ve led have successfully utilized process enhancements to drive improvements in productivity, overall capacity and quality within various organizations large and small.  Utilization of a known process allows you to begin to measure various pieces of the lifecycle – looking for inefficiencies and issues that impact your overall ability to deliver for the organization.

Now all that said, each organization needs to find the lifecycle process and development paradigm that will work with their culture.  I’m not going to try and tell you what development paradigm you need to follow because I don’t know your organization.  Within the organization I currently work for we largely follow a waterfall process with some agile techniques utilized within various teams.  This works for us and the style of applications that we create/support – mostly technical interfaces within the payments industry.  Our overall lifecycle has various checkpoints/gating that we use to validate we are ready to move to the next stage.  This works for us!  We’ve significantly increased our productivity and capacity over the last decade and have improved the overall quality of applications that we are delivering to our production environment.

While all this has been good, I occasionally notice when people are hiding behind the process versus just getting the work done!  Not every project needs every step of the lifecycle.  Some are small enough and straight forward enough that we can skip various parts of the process or make the decision not to create some of the standard artifacts/documentation.

Decisions need to be made up front when the project is defined.  Those in the know, need to direct the teams when a project needs the full pomp and circumstance of the lifecycle and when the teams have the option to skinny up the process and skip parts of the lifecycle.  That means at the very earliest stages of Discovery, the Project Sponsor should be giving direction to the team on what the risks are associated with the project which can then drive decisions on how much of the process can or should be used on the project.

Additionally, once a project has been initiated, I think individual team members need to be cognizant of what is happening and make recommendations to the Project Manager if they feel certain pieces of the lifecycle could be skipped or maybe some documentation might not need to be created.  I’m not saying that we’ll always make the choice to skip over pieces of the lifecycle or to not create various pieces of documentation, but as leaders, we need to listen to the recommendations of the people closest to the work and if it makes sense, say yes!  When we decide that we can skinny up the process used within an individual project or that we can eliminate some of the standard documentation, those decisions should be documented.  That way, there is a record of the decision and the reason is documented and shared with the Project Sponsor.

Overall, we still need to deliver for the organization!  Delivering the requested solutions with the necessary features/functionality; delivering a solution at or below the expected budget; delivering a solution with the highest levels of quality.  Our teams should be held accountable to ensure we are delivering successful solutions at the end of the project.

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

Picking your own Path!

I’ve been around the block for a while now.  Later this month I’ll turn 51 – which means I’ve seen all sorts of things during my career.  I’m lucky – I love what I do and I knew I wanted to be in software development very early in my life.  I touched my first keyboard when I was 12 and began programming in Basic on a DEC PDP 11/70.  And if that alone doesn’t date me, my first programs were created on punch cards and teletype terminals – yep a keyboard with green bar paper running through it that would physically type out the commands entered and responses would come back and print on the green bar paper.  The smartphone I have in my pocket has significantly more power than that first computer I used.  My Nana always used to joke that I was going to fry my brain working on those ‘computers’!

I also knew at a young age that I eventually wanted to be in management.  I had grown up watching my dad run various companies – some failed, others were successful.  While I was in high school, my dad started the final company that he would run – it became very successful and provided him with years of enjoyment until he retired several years back.  Exposure to these companies and the environment in which my brothers, sisters and I grew up in made me realize that at some point in my life I wanted to be in a leadership position – I wanted to run the world!  If I had only known then the growth I would need to be in the position that I hold today!

So why am I rambling on about my early career?  Well, at one point, I had several people attempt to convince me not to move from development into a management role.  I was reminded of this recently because someone that I’m acting as mentor to, is having the same experience.

Moving into management is tough for someone who is in a technical role.  I’m not saying it isn’t tough for other professions – it probably is.  That said, I’m speaking from the personal transition I went through.  I was used to being the one in control – at the end of the day, I could look back at the success I’d had that day pounding out the code.  I was good at what I did – I liked the tough technical problems and my managers relied on me to solve problems.  I absolutely enjoyed being a developer – it was fun, I got to solve problems, I got to play with new stuff that nobody had ever seen, I was recognized for being a person that could just get stuff done.

Eventually, I got to the point where I decided I wanted to transition into a management role.  As I began to tell people that management was something that I wanted to try.  I got feedback from all over the place that I should just stay where I was at, to eventually become a lead or an architect.  Many folks had an opinion to share and staying technical seemed to be the theme behind most of the comments.

Well, for me, it came down to what I wanted not what other people wanted for me!  This is important; you can’t let someone else determine your path forward.  If you know what you want to do with your career, then you have to make it happen.  You can blindly sit there and wait for someone to notice you and maybe give you the opportunity, or you can take proactive steps that will get you into the position you want to be in.

I recently sat down with someone who is contemplating making a similar move in their career.  We had previously discussed this “change” in their career and I know that the individual has communicated with their boss about finding a path between their current role and into a management role.  This individual than began to tell me of all the feedback they were getting from all over the place on why they should stay in the role that they are in.

I let this individual pour it all out on the table.  Then I asked them, "who cares what everyone else wants, when you look at yourself, what is it that you ultimately want to do with yourself?"  Now, I fully recognize that this individual is really good in their current role – and I mean really good.  That said, how happy are they going to be in the future if they at least didn't try?  This individual didn't hesitate, looked across the table and said, “I know I’m meant to be a manager!”  My reply, “Then why are you letting other people create doubts about what you can become?”

I have no doubt that this individual will experience some challenges moving out of the role they currently play and into a management role.  I also have no doubt that this individual will be successful in either role.  I also know the people this individual works for will provide the support needed to transition into the new role – they've done it with other folks on the team!

Sometimes you can’t listen to those around you and you need to chart your own course.  Don't be afraid to make a change and when you make the decision - proactively take steps to make it happen!

See more about my life in technology via: http://anidea4today.blogspot.com/

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

Practicing What We Preach …

This week, I got a small dose of humble pie from our CIO.  I was in his office discussing the difficult time that one of my teams was having filling a key position.  Finding someone is critical to the success of this team and it has been difficult finding candidates that would be able to come in, hit the ground running and make a difference.  We have key criteria for this position, and I’m not willing to budge – this is one of those times where I don’t have the luxury of training someone, I need someone with a specific skillset and experience.

Before everyone goes all crazy on me for speaking out both sides of my mouth, I normally utilize a very aggressive internship program to fill open positions within my team.  It is rare that I hire experienced candidates.  When I do, I am very specific about what I am looking for and I stick to my guns.  I won’t hire someone just for the convenience of filling the role, I will wait until I find a candidate who fits the needs that I have and that be a net positive for the team.  I’ve bent in the past when I felt I just needed to get a body in the door, and it’s a painful experience.

So, then, let’s get back to the story.  I’m sitting in-front of my boss – our CIO – explaining what steps I’ve taken and where we are at in the process.  He’s letting me vent and as we get close to wrapping up this part of the discussion he asks a simple question, ‘Have you considered hiring someone remote?’

Whack – right to the center of the forehead!  Ok, so you need to understand for the last several years, I’ve been the most vocal proponent inside the organization to allow our team members to work remotely.  We have successfully introduced it into my teams and this has slowly crept into a couple of other areas of the company.  This has been allowed in a very limited fashion, but has proved to be successful enough that a key member of our team moved to another state and organizationally, nobody questioned his ability to continue working for us when he asked if he could do so prior to moving.

Additionally, via an acquisition several years back, one of my teams is split geographically with the manager located at our main facility with half of his team and the other half all working in disparate locations across the southern US.

So there I am the biggest proponent of getting people to work remotely sitting there in front of my boss looking like a fool! Organizationally, we are ready to expand this program.  In fact our COO has recently spoken about the need to show flexibility in where our teams are located.

What could I say, but, ‘You’re right! I guess it’s time for me to step up to the plate and take the next step and push this program forward!’

As leaders within an organization, we have to remember the things that we are fighting for and when given the chance, we need to implement those changes into the organization.  Our bosses expect it of us and we expect it of the people that report up through us – we need to remember, the same rules apply to us.

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

It's NOT about the Tech or the Process - it's about the Customer!

This week I have the pleasure of participating in the annual SHAZAM Forum!  It is an event that my organization holds each year to keep our Financial Institutions informed on key trends within the industry.  Over the next few days I will have the opportunity to interact with hundreds of our customers.  To listen to their stories, to understand their needs and to enjoy some time together.

Let's be honest, as much as I care about the tools that we use and the processes that we have in place.  Our customers really could care less.  They care about that fact that the systems we provide will function - that they can open a new account when someone walks into one of their branches, that they can process a loan when one of their commercial customers needs a new piece of equipment, that their account holders can login to their internet banking site and transfer money between accounts, that their account holders can use their debit card when purchasing groceries at their local grocery store and that when I detect some fraudster starting to steal their customers money - that it is stopped.

They really don't care that I use Java or C++, they could care less if I used Agile or Waterfall project management paradigms.  They don't think about the various testing methodologies in place to prevent bugs from impacting their ability to perform their work.

Put simply - our customers want and deserve to be delighted when using the systems and services that my organization provides.  They don't want to know the details of why or how we made decisions and built the services/systems, they just want to be able to use them to conduct business with their account holders.

I look forward to our annual Forum because it's my opportunity to get to know the folks that choose to do business with the organization that I work for; I get to hear what is important to them; I get to listen to the frustrations that they have using the systems that my teams build; I get to listen to the concerns that they have about the market that they serve.

Let's be honest, on a daily basis, most individuals within an IT organization have very few opportunities to interact with the customers of the systems that they build.  I'm intentionally not counting the internal customers.  Internal customers are important, but they do not provide a true reflection of what our Financial Institutions, their employees and their account holders are challenged with on a daily basis.

It's important to occasionally step away from the technology and immerse yourself in the world that your customers deal with every day.  To understand their interactions with the systems and services that you build so that you can understand what needs to change in future iterations.

In other words - it's not all about me, it really is all about the customer!

For those of you that will be attending our Forum - I look forward to seeing you again this year or meeting you if it's your first time!

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

Logic and Project Management!

As a child, I was glued to the television whenever there was an opportunity to watch Star Trek!  I loved the show - campy by the standards of today, I couldn't help myself as I wanted to be on the Starship Enterprise as she traveled to the stars.  And, yes, my favorite character was Spock - followed closely by Scotty.  Spock in may ways spoke to many of us - using logic instead of emotion to solve problems.  And when he did let his emotional side out of the box - showed that emotion could and would frequently lead to painful mistakes.

So, why am I using space within a blog focused on project management and applications development to discuss Spock?  Logic - use it to succeed within your role.  Strip aside the emotion that you feel when confronted with issues and follow the facts!  Stay calm, track down the details and use those details to identify the move forward solution.

No project of any realistic size moves from idea to implementation without some sort of issue rising up, ready to take the whole thing off the rails and into the ditch.  Some problems are small and others tend decloak themselves like a Klingon battle cruiser to surprise and fire upon your Starship Enterprise!  These incoming salvos threaten to overwhelm you, the team and the project.  At this point, you can either act emotionally, running around without a plan and make the problem worse.  Or, you can act like Spock - use logic to create a plan, execute the plan and overcome the issue.

Planning:

Sometimes with a small issue, you can 'wing it' and successfully manage the issue.  That said, the larger the issue, the more likely you will need some type of plan and process to deal with the issue.  Leadership in the organization is going to expect you to communicate the issue, progress in finding a solution and then progress against whatever plans are ultimately put in motion to resolve the issue.

There will be wide variety of additional items you will need to manage within the overall effort:

1. You may need to setup a research team to investigate how the issue was missed or what the cause of the issue was so that this information can be communicated to the management team.
2. Additional personnel resources beyond the original scope of effort associated with the project to identify the overall solution as well as assisting in any work needed to implement the solution.
3. Additional budget resources beyond the original scope of the effort to cover any additional internal or external resources needed to provide the overall solution.
4. Communication plans may need to be put in place to update internal resources, communicate with and manage customer expectations and manage any risk to the overall reputation of the organization.

Each of the above items will require management effort from the Project Manager to ensure that future milestones within the overall effort are adjusted and manged properly; and to coordinate activity between various team members, departments, and outside consultants.  All of this will take careful planning, using organizational skills to minimize the impact to the project.

Methodical:

Many times as a Project Manager you are dealing with choices - making decisions about where short-cuts can be taken; making decisions on whether to go with Plan A or Plan B when there is no consensus from the team on which direction to take; sometimes sifting thru agonizing amounts of detail to understand an issue so that it con be communicated to the management team.

As the complexity of a problem increases, the number of details being tracked or managed associated with the issue will grow beyond your minds ability to track them all.  You are going to need processes in place that allow you to align the issue resolution within the overall tracking mechanisms in place to manage the project.

1. You will need to track new data points within and aligned to the overall project - new milestone dates, budget information, new internal and/or external resources, new equipment that may need to be purchased.
2. You will need to realign your current schedule to accommodate any new milestones associated with the new effort.  Especially those new milestones that will require current or future activity within your plan to be delayed or altered.
3. You will need to ensure that communication plans are executed properly not only to manage internal expectations, but just as important to ensure that customers, vendors, the media and other 3rd parties are kept in the loop.

Your role as Project Manager requires that you have a plan, that you execute the plan and that you manage the expectations of your team members.  You need to be the calm within the storm.

Detail Oriented:

Team members are going to be hitting you with lots of information - your job as Project Manager is to sort through the minutiae and ensure that the relevant data is recorded, tracked and used to make decisions throughout the overall project lifecycle.  As Project Manager, you will be expected to identify the important pieces of data, communicate that to the team and ensure that the information is available within meetings as decisions are made on the forward progress of the project effort.  

Additionally, management will expect that you understand the relevant pieces of information within the flood of details and know when to present that information up the ladder.  Many a Project Manager or Manager have failed when they have forgotten to keep the leadership team informed on decision points and the underlying information used to make those decisions.  I'm not saying that you should have the expectation that your being micro managed - but when there is an unforeseen issue that crops up, over communication is necessary to ensure that everyone understands the nature of the issue, the solution being implemented and the overall impacts to the organization.

Logical:

You can be angry and frustrated - that however is not going to help you move the ball forward and find a solution.  At this point, you need to step away from your emotions and use logic to understand where your at, what data points you have available to make a decision and then make short and long term decisions based on that information.  Knowing that you can adjust future activity and decisions based upon additional data points that surface.

Spock would 'follow the facts' to get to the answer - wherever those facts happened to lead him.  That's your role!  You will be tempted as angry and frustrated team members, management, customers or 3rd parties call you or come over to talk with you.  At times, you will want to 'fire back' at the individuals - however, it is better to step back, take a breath and then approach the conversation.  Focus on the fact, just the facts!  Use logic - it is the best tool you have at your disposal to deescalate the situation.

Mr. Nimoy, you are and were an inspiration to many of us ... may you live long and prosper among the stars!

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