Accountability ... It's For Everyone!

Accountability: the state of being accountable, liable, or answerable.

Software Engineering is as much art as it is engineering. From the engineering side, their are best practices that guide developers on how to structure code, ensure the contracts between functional silos are maintained, ensuring performance constraints are adhered to, etc. On the creative side, there are a million different ways to write a specific function, as code is created, the engineer has the ability to choose how the exact implementation will be constructed.

From a management perspective, it can be hard to set and ensure that our teams are on track with specific milestones. Over the years I have tried several different tactics. Some have worked better than others. Recently, I've come to believe and rely on the following as a way to ensure that the leaders within my team have a pulse on what is going on within their teams and can actually provide factual responses to the question of 'where are we at'.

First, we established daily stand-ups within each of the resource teams. These run separate from any project related meetings/stand-ups that the project managers may run. Our goals with this 15 minute activity are to:

1. Open up communication within each of the respective teams and let every team member have visibility into what is happening.
2. Ensure that there is accountability within the team - everyone knows what the promise is and has to speak to what they've accomplished and what is coming up next.
3. Give the leaders of each team insight into current tactical activity to ensure that team members are working on what they are supposed to be working on, eliminating unplanned work, shifting resources to address roadblocks, and validating that the appropriate progress is being made to meet the established milestones.

These meetings run quickly - typically 15-20 minutes and each team member goes thru the following items:

1. What did I accomplish yesterday - was I able to deliver on what I promised.
2. What roadblocks am I encountering - do I have a path forward or do I need assistance.
3. What is my promise for tomorrow.

I am not able to attend every stand-up for every team, but I like what I'm seeing within these meetings. Team members are engaging with each other and have a better understanding of what all is being worked on within the team. When there is a problem, people are offering to jump in and help resolve the issue. When people have a little bit of down time, they are volunteering in the meeting to help other team members out with their tasks or are jumping ahead on stuff that still needs to be done.

These simple questions and setting aside 20 minutes a day to discuss, has altered how we are handling things within the team. First, I believe we have significantly reduced the unplanned work. Second, we have much better visibility into when a team member might be stuck and people are jumping in to help - either by just talking things thru or actually getting on the keyboard and solving issues. More importantly, I would also argue that my teams are communicating better. Communication is the key to everything, if we talk with each other, we solve problems and create wins!

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

Be the change, don't wait for change!

Let me walk down memory lane for a few moments. My first formal job in the technology field was actually not doing software development, but was in sales and training. I sold IBM PCs, Compaq Computers and System 36’s. I was also expected to teach courses for the store that I worked for – Lotus 1-2-3 and dBase III. For those of you with memories going back that far, yes, I’ve dated myself. I would venture to state that most of the team that work with today, would have no clue what a Compaq luggable computer was nor even understand what an IBM Baby 36 looked like.

I sold computers for a year before I found a company that would hire me as a developer. While I did well with the sales aspect of it, I knew that selling was not my cup of tea and was not something that I wanted to pursue as a lifelong career. Getting that first development job felt right. Ok, I had been doing contracting since I was a teen, so this was really just coming home to what I knew I was meant to do. Pounding out code was comfortable, solving problems gave me a rush and was what really fed my soul. It was good to know what I wanted and then to find a company actually willing to let me pursue my passion.

I was hired to come in and develop software using Clipper (this was a compiled version of dBase III). Creating financial solutions for a very specific industry. I learned a lot in that first professional development role. How to truly plan for and test code – testing was not an afterthought, but something that was worked on just a diligently thru the development process as was the actual coding. I learned how to work on a team – understanding the role of the people creating the requirements, performing user testing, performing QA testing and then having to package up and deliver the code. Team also meant working with other development engineers to ensure that the stuff I was building fit with the stuff that they were building. When I was doing contracting, I was a one man show and did not truly appreciate the interactions needed to fit my stuff in with the work everyone else was performing.

Over the years I have had to learn and use several languages. In middle school and high school I formally took a Fortran course and taught myself how to code in basic. I can’t remember if I took Cobol or Assembler as a class, but I know by the end of high school, I could use both of those languages. Assembler was not something I enjoyed, but I could do it. I had also learned how to program using Basic. So, by the ripe old age of 18 I was able to hack around with 4 separate languages. College reinforced Assembler and added Pascal into the mix, along with several different theory courses. While I was acting as a sales rep, I was able to have access to a Compaq luggable and during the evenings I was able to teach myself Turbo Pascal. I also taught myself dBase III and was able to get a hold of the Clipper compiler and teach myself how to use that to compile the dBase III programs I was creating. Since then, I’ve taught myself additional development skills – C, C++, MS Visual Basic, CA Visual Objects, Java, Python, Ruby, Ruby on Rails, JavaScript, PHP, Objective C, Swift and others. I’ve also figured out how to use HTML, CSS and other web tools. This doesn’t include all the frameworks that I’ve learned along the way. I will be the first to admit that I’m not an expert in most of the previously mentioned languages, but I at a minimum can hack my way thru a development session using the languages mentioned above.

Why am I listing off all this stuff? Well a couple of reasons:

1)      Lifelong learning is critical within the technology arena. Those who think that they can learn 1 or 2 things and use that their entire career are in for a world of hurt. I would say over the last 30 years, the pace of change and expectations of picking up different development skills has accelerated – much the same as in other professions. Today’s focus on DevOps and other paradigm shifts, is forcing developers to learn new skills and become even more adaptable.

2)      There is a tendency to ‘get comfortable’ and develop new code using technology that you are familiar with – you can get it done quicker! However, at least in my organization, I sometimes need/desire to have people jump between teams and this requires that they be able to utilize different technology skills – C++ vs Java vs Objective C, with a little Python thrown in here and there to make things interesting.

When I first started programming there was no internet, no on-line help, no instant messaging to help me figure out how to get around different programming problems. There were thick manuals that I had to sit back and read. Today, engineering teams can use the internet to find solutions to problems, to find sample code or entire libraries/code that solve the particular problems that they encounter.

I remember having to write my first authentication and control system to wrap around a system. Today, I can go out to git and find dozens of complete libraries that perform basic application authentication to complete 2FA and access control within applications.

The tools available today make it much easier for developers to gain a basic proficiency of a given language. You can find on-line tutorials that guide you thru downloading a new language, creating your first project and stepping you thru the ins and outs of the frameworks. I would have killed to have access to those types of tools as I was starting to develop software.

As software engineers, we shouldn’t be afraid to pick up new skills. As leaders, we should be encouraging our team members to take a look at the new languages, scripting languages and frameworks. We should all be looking at ways to increase our efficiency, deliver functionality faster, increase the quality of what it is we are building and keep an eye on emerging trends that may impact the systems we create and support.

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

Recapturing our Youth!

This has been an interesting period in my life. My wife and I recently moved our youngest son out of the house into his dorm, so that he could begin his college experience. It was a really incredible day, seeing his excitement and watching him and all the other kids in the dorm move in. Yes, we were busy setting up the room and getting all of his stuff tucked away. Yet, while all this was occurring kids were wandering the halls beginning to meet each other. The excitement was visible, everywhere!

Over the last couple of weeks, he has made it a mission to visit each of the floors in his dorm, using a Frisbee to start up conversations and get to know the people he now lives with. He has wandered into other dorms in an effort to get introduced to more people and build his social network. He and his friends have introduced themselves to people tailgating the football games and expanded their social circles. He seems to be on a mission to get to know as many people as he possibly can – yes, he thrives on social experiences.

Looking back at my own experience as I made the transition from home to college, I remember the fear, the excitement and the fun of leaving home, meeting new people and having new experiences. It got me thinking about how change is viewed in the office, let’s just say it is not necessarily a positive within our teams.

Let me walk thru a recent experience – over the last year we have been introducing the use of Kanbans as a tool to visualize enterprise project activity across the organization and within my teams using team stand-ups to talk thru the tactical daily promises. Our daily stand-up meetings are focused on simple communication – what did you promise yesterday/did you deliver, what roadblocks are you encountering and who needs to jump in to help remove the roadblocks and what are you promising for tomorrow. Can we move the card on the Kanban? Yes, we are crawling before we walk, walking before we run and running before we try and leap. These are things that many folks within the organization and within my teams have advocated over the last several years.

We are not fully Agile, not sure if we will ever get there, but we are trying to use some of the tactics within projects where it makes sense for us.

What I find interesting is the pushback we have received along the way. I was expecting some of this, but was surprised when some of the very people promoting Agile techniques began to resist the actual implementation of some of these techniques. Some of it came down to – well if you aren’t going to implement and adhere to the entire Agile principles, than how do you expect me to get onboard. Other times it came down to, well I’m not really comfortable trying this in-front of other people.

I get it, we hate change. But when did that shift occur? Again, I look back to my sons as they grew up. They constantly were experiencing change, each year asking to take on new responsibilities. Tackling new topics at school, meeting new teachers, being a part of school sports, taking on roles within the student council. Outside of school, trying various sports when they were younger and then adjusting to changes as they progressed with their athletic talents. Sometimes taking on leadership roles, other times acting in support roles. They grasped for these opportunities, not expecting failure and looking for the next challenge.

Yet, somewhere in our path to adulthood, we start to resist change. We like the stability of knowing what it is we are doing, what comes next and who does what. The funny thing is we talk about change, until it happens to us.

Ultimately, we need to be agents of change for the companies we work for today. In the past, there were periods where businesses did not need to worry about rapid change. That dynamic is no longer true, businesses must continually evaluate the products and services that they are providing, the competitive pressure of local and international competitors. If you’re not constantly ensuring that you are serving your customers, your customers will walk away.

I encourage you to recapture that spirit of youth where you wanted change. Where you weren’t afraid to accept change. If our businesses are going to succeed, we need to continually change to adjust to the needs of our customers.

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

Staying Out Of The Weeds!

As a manager, you can’t be successful if you are always injecting yourself into the tactical decisions being made within your team! This is called micro-management and will demoralize your team members and sooner or later, will drive your best team members out of the organization. Turnover is expensive and makes you less effective as a manager.

So why is it we as managers struggle with this? Why do we keep injecting ourselves into decisions that don’t need our input? Don’t read on if you don’t want to look in a mirror.  

One word – fear!

We jump to the conclusion that our assessment of the situation is unique, that only we can solve the problem and that if we don’t provide direction to the team that they will fail. I hate to say this, but if you don’t trust your team to make the tactical decisions, than you’ve hired the wrong people, you’re not mentoring them properly and you’re not providing them a path for success.

Most managers work their way into management by showing success as an individual contributor. When they make the leap into their first leadership position, they continue to think as an individual contributor versus taking responsibility and delivering as a team. Over time, great managers figure out the change and begin to operate differently. Unfortunately, there are some managers that never figure this out and not only harm their own team, but harm the extended team. Ultimately, this can lead to breakdowns  that impact your customers.

So, why do we need to break away from the detail? Shouldn’t we ensure that the team is successfully delivering against the active projects? Well, yes, you need to ensure that the team is delivering against active projects and work, but that doesn’t mean you have to manage the blow by blow of every activity underway within the team. Your primary role as a leader of the team is to remove roadblocks before they impact the team and to act as an escalation point when the team hits a roadblock that they are not able to overcome using standard processes and procedures.

Removing roadblocks before they impact the team - say what? Yes, as the leader of your team, you should be looking at the status information being fed to you and looking at patterns that indicate trouble may be on the way and looking for ways to mitigate those issues. This means you have to correlate the information being fed to you and looking out in front of the team. Sometimes this is listening to the risks and issues being identified by the team, sometimes this is seeing a pattern being reported by multiple sources within the team, sometimes this is listening to folks outside the team that will be impacted by the work product. However you receive the information, it is your job to work ahead of the team and resolve the issue so that they can continue to deliver to the department, the overall organization and your customers - internal and external.

Additionally, when they come to you with an issue that can not be resolved within the team, they are looking to you to pave the way forward. You need to reach outside of the standard silos within your organization and outside the organization to find solutions that allow the team to get back on track and deliver. Sometimes that is going to require you to think outside the box and change the parameters - your job is to find a win, win, win situation. A win for the customer - internal or external - that will rely on the end product from your team, a win for the organization by staying on time, under budget and with the necessary quality constraints, and a win for the team by giving the success they seek.

Nobody on your team consciously wakes up in the morning and makes the decision to fail! These folks are working to make their dreams come true, to care for their families and to make a difference. Your job is to give them the opportunity to succeed.

And I’m not saying, you’ll always succeed at removing the roadblocks. But your team needs to at least see you making the effort to help them find success. They want to know that you’re in it with them.

Being a leader of your team is not easy! But the more your stay in the details and forget about what your team really needs from you, the higher the risks are for their failure and ultimately your failure.

I’ve worked for micro managers. It’s not fun! They prevent success and they drive good people out of an organization. Look in the mirror and ask yourself, what am I doing today that will help my team succeed?

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

Project Management Is Such A Lonely Phrase

Project Management, is like the word honesty from Billy Joel’s hit song titled “Honesty”.  Project Management is such a lonely phrase!

Let’s get down to the brass tacks – Project Management at its most basic function is responsible for managing the three sides of the triangle: time, budget, and scope.  Project Management requires the Project Manager to utilize their knowledge, skills, tools and technique to oversee a team of individuals and deliver against the Project Requirements, within the allocate time and budget with the approved resources.

If a Project Manager is to be successful, they must view themselves as the only source of truth.  At times, they must set aside the need or want to be liked by the team so that they can provide a true assessment of ongoing activity to the Project Sponsor.

Let’s face it, at times, the teams like to sweep issues and risks under the table so that they can present a warm and fuzzy view of the project to the Project Sponsor and the Project Management Office.  The Project Manager sometimes enables this behavior because they want to see their status in a ‘happy state’.  This also reduces tension within the team, because the Project Manager is not confronting the issue.

Well, that’s just plain wrong!  I’m sorry, but as a Project Manager, you role is to highlight to the Project Management Office and the Project Sponsor when tasks are not being completed on time and the risk to the overall project.

Now, I get it!  Not every task will be completed on time, but there are milestones that activity should be tracking to that allows the Project Manager and others to get a sense of whether a project is on track or not.  A given task may be late, but not risk the overall milestone.  However, if the milestone is at risk, either from a time or budget perspective, than the issue/risk needs to be highlighted, mitigation plans need to be identified, and communication needs to occur.  It is possible that thru the mitigation plans identified by the team that the Project Sponsor will allow the team to address the issue or risk.  However, if it is a key milestone and the Project Sponsor is not comfortable with the mitigation plans, they then have the opportunity to engage and assist the team in getting the issue corrected.

As a Project Manager, you are the source of ‘Truth’ for the project.

Resources like to always look at their own package of work and paint a rosy picture.  They will find reasons – not their own – as to why something is late, or why it’s costing more than was budgeted.  As a team, they will work together to gloss over the truth and allow the Project Manager to report a rosy picture from week to week.  I’ve heard things like:

•      Yes, we are running over the timeline to get requirements complete, but we’ll make up for it somewhere down the line.

•      Yes, the designs aren’t ready to go, but everyone knows the estimates put together for the actual construction are way high, so we’re good.

•      I know development is taking longer, but we don’t actually need all the testing time that is shown in the plan.

•      The contract firm that is doing that piece is late, but that’s ok, we can still get all of our pieces in on time.

None of the above statements (or any other excuse) is acceptable.  As the Project Manager, your job is not to go along with the team. Your job is to identify the issue, create a mitigation plan and communicate it up the chain to the Project Management Office and the Project Sponsor. Once the issue has been highlighted, maybe additional resources can be applied to bring the timeline back in and meet the next milestone. Maybe the Project Sponsor accepts the recommendation from the team that the milestone can be missed, but the overall plan can still be delivered within the identified timeframe. But at least, the Project Sponsor and Project Management Office are aware of the issue and can work with the team, vs being surprised at the very end that a project is being delivered late or over budget.

As ‘truth brokers’ you are keeping the team members honest with each other and are keeping the lines of communication open up to the Project Management Office and the Project Sponsor.  This truth is critical as it allows the Project Sponsor to accept the truth without questioning the motivations and ultimately forces clearer communication between team members. 

Telling the truth should not be viewed as a negative, but should be viewed as the core responsibility of the Project Manager.

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

Rock Star Programmers - 5 Traits I See As Winners

In my heart, I’ll always consider myself a professional software developer.  I began writing code at the ripe old age of 12.  While I don’t write code on a daily basis anymore – the sin of being ‘management’ – I still write code at night to keep my skills fresh and to ensure that I can sit in a room with my development team and understand the conversation and hopefully add value.  While at one time, I considered myself an expert in the languages I used (don’t ask, they are all now ancient).  I realize now that I can still write good code – but because I don’t do it day in day out, I don’t kid myself in thinking that I’m the whiz kid anymore.  I’m not.  I’ve got team members that are extremely talented and I’ll give them praise any chance I get.

So what makes a great developer?

Over the years I’ve watched a lot of developers come and go in the shops where I’ve worked.  Some of these folks couldn’t code if their life depended on it and didn’t last long.  Others made it look effortless – producing code that was simple, easy to read and just seemed to work.  So what made these developers different, what did they do different than everyone else?

Patience

Some programmers get their assignment and without asking any questions start pounding out the code.  They’ll quickly listen to what is needed or skim the requirements and get to work.  They’re dismissive of further explanation, and are quick to say that they know what the users want better than the users of the system.

The best programmers take their time.  They actually read thru both the requirements documentation and the technical designs if they exist, or they’ll spend time interviewing the user to understand what the true problem is and what issue is being solved.  They are not only concerned about what it is that is wanted, but they take time to understand what isn’t wanted or needed in the solution.  These developers think not only about the specific assignment but want to understand how it fits into the whole puzzle.  Are there parts of the system that operate ahead of their piece – what do those parts of the system do to the data before it gets into the code that they are writing?  Are there parts of the system that will need the output of the code that they are writing?  How do they ensure that the data is validated before it leaves their code and is handed off to code written by another team member?

Lifelong Learner

Coasters – they drive me nuts!  These are the folks that think they know everything and that they are better than everyone else on the team.  They scoff at junior developers and will tell them that there is nothing that they can learn from such a junior team member.  The Coasters are forgetting that anyone can be a teacher.

On the other hand, I love lifelong learners.  These are the developers that are constantly pushing themselves to learn new technology, understand how to use the language they are developing in more efficiently.  They are constantly reviewing everyone’s code and are not afraid to take a chunk of code, walk over to the person that wrote it and ask them to walk them thru the code so that they understand what is happening.  They aren’t afraid when someone critiques their code and in fact actively pass their code around to others on the team to be examined.  When you run into them in the breakroom or walking thru the office, they will begin telling you about the new scripting language they are playing with or some new solution/tool/framework that might make the team more efficient.  Give these folks room to play – they will make your team better and find unique solutions to some of the toughest problems you have.

Commitment to Excellence

We know these folks – the developers that quickly write their code and then throw it over the wall for someone else to test.  They’re not concerned about what happens downstream – heck, they’re not even concerned about what happens within the code they just wrote.  They spend more time fixing their code than they spent quickly writing the code – in this instance, speed does not win the race.

Flip that around now.  The best programmers take their code personally!  They view their code as a direct reflection on themselves.  The best programmers will actually create their battle plan prior to writing any code – understanding exactly how they will test what is being created or modified to ensure that it works within the complete workflow.  Reviewing all of the incoming data, understanding what they should and shouldn’t expect.  Reviewing all of the output and integration points and understanding how the data can be manipulated and what are false values or boundaries of the data.  They will write small chunks of code or use scripts to test the code they are creating/modifying.  They are not only implementing unit testing, but are thinking through integration and regression testing along the way and then executing prior to handing off the code.

Passion

Look, if you don’t like your job – find something else to do.  We know these folks, they slouch in, plop down, ignore their fellow team members, don’t offer to help others, won’t bring new ideas to the table, won’t participate in meetings – team or otherwise and won’t do anything but exactly what they're told.  Are you kidding me!

Now, show me someone who is passionate about what it is they do!  Yeah, that’s the ticket!  I love these folks – they live and breathe to be the best coders out there!  They’ll call themselves a geek – and view it as a sign of honor!  They aren’t afraid to tackle the most complex parts of a project.  They find a way to practice their skillset – just like the best musicians.  If they’re given a particularly difficult task, they’ll try 2 or 3 different solutions to find the one that works best.  They are disappointed in themselves when they miss a deadline or someone finds a bug in their code – but they are the first to step up and take critique.  They view critique as a lesson along the way, will actually listen to it and attempt to learn from that criticism.  They will throw themselves at new technology when asked – and in a lot of instances without being asked – so that they can become more efficient.  You’re hired!

Self Sufficient

There are days I’ve pulled my hair out because someone will tell me that they hit a wall and couldn’t get any further.  When I ask them what the issue is, they tell me they’re waiting on answers to clarify some problem in the code or with the requirements/design.  When I ask them what they’ve done to solve the problem, I get a blank stare after they tell me they sent an email out 2 days ago.  Really, you couldn’t find it in yourself to stand up, walk to the other side of the building and get an answer?  Ugh – do I really look like I want to play baby sitter!

Now the best programmers are bull dogs!  They hit an issue and they are tracking down the best way to get the answer.  Sometimes that is tracking down someone internally, sometimes that is looking on the net to find a solution to a particular programming problem, and sometimes that is asking a team mate sitting a few seats away.  They are not afraid to ask questions and understand that communication can be used to solve issues!  If the issue is big enough, they don’t hesitate to escalate the issue – but usually have a couple of different options to resolve the problem.

Wrap Up

These have not been presented in any particular order, but they do represent the traits that I see in the best developers.  They are traits I attempted to show when my main role was to sling code every day and that I hope I still possess in the role that I currently play.

What are the traits that you see within the best developers you have on your team?  Let’s keep the conversation going!
 

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

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