Category: Project Management Page 2 of 3

Going from Software QA to IT Project Management

Software QA

My journey in the world of IT began as a quality assurance analyst. For UPS, I would test and certify applications used in operations. I spent most of my time in the test lab with the rest of the lab rats. Testing software back then was the easy part, the hard part was building the right platform. Performing a ground up install of MS Windows Pro could take almost half a day and if it failed, you’d have to start over again. If you were lucky you got to use a ghost OS image, but even those presented their own challenges.
 
Later in my career I would go on to focus less on hardware and more on testing software. With Accenture I worked along side large testing teams on huge multi year waterfall software projects. We would create test plans consisting of hundreds of test scenarios. We then charged off to complete all the testing in a matter of weeks. Anyone who worked in QA (or dev) can attest to the agony of the waterfall project death march experience. Pressure from management, late nights in war rooms, and working weekends combined to make the QA role a nightmare.
 
Fast forward to the arrival of Agile and my role in QA became tolerable again. Instead of having a mountain of code dumped on me for testing, now I could test small chunks of software in two week sprints. The only problem was (and still is) that many organizations struggle building shippable software in sprints. This results in companies that are waterfall masked as Agile.
 
After almost a decade working in QA I decided I to get into project management. I always enjoyed connecting with people and I felt project management better fit my strengths. Through the guidance of mentors, lots of studying and hard work, I was able to become an associate project manager. After time I was able to work on larger projects, consulting for large companies.
 
Making the transition into project management was a great career choice for me. Project management much better aligns with who I am. For you it may be different. Your passion might be in QA and there’s nothing wrong with that.
 
If you are someone who works in QA and you’re considering get into project management, my advice is to go for it. Software QA analysts make great project managers because they are battle tested. I discussed this more in my last post “The identity crisis of the IT project manager“.
One thing’s for sure, if you’re not happy in your current role, don’t settle!

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master.

Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

The identity crisis of the IT project manager

The IT project manager role is one of the most in demand and sought after positions in technology. Ask any hiring manager and they will tell you that finding a good IT project manager is difficult. I’ve seen people with the most impressive credentials crash and burn trying to manage IT projects.

So what exactly is an IT project manager, and what makes a good one? The IT project manager used to be the person accountable for managing scope, schedule, and budget for IT projects. Today, that’s still true, for the most part, but the role has a bit of an identity crisis

The Project Management Institute, with their PMP certification, says the role is all about planning and control. If you’ve taken the PMP exam, you know PMI teaches you to create a large project plan. Within that plan are many sub plans for each area of the project.

The PMI has come under scrutiny in recent years by the technology community, and for good reason. With the rapid advancement of technology and globalization, organizations need to be agile. Planning is important, but responding to change may be even more important. Our systems and organizations have become too complex for the PMI plan and control model. This need to adapt to change is what has fueled the Agile software development movement.

With the increase of self-organizing agile teams, it brings us back to the question, what is the role of the IT project manager? Is it an Agile project manager? Is it a project leader? Is it a servant leader? Is it a Scrum Master? Is it a tech lead?

The answer depends, but the role may consist of a combination of all these things. One thing we know for sure is that the IT project manager is a change agent and a leader.

To succeed in this role, one needs to have both hard and soft skills. Good IT project managers use both the left and right hemispheres of their brain. The right side of the brain used for cognitive thinking, the left side for emotional intelligence and relationships. This enables them to be both technical, and emotionally intelligent. Project management is both a science and an art form.

If you are looking to get into IT Project management, you better be able to deal with chaos while keeping your cool. If you currently work as an IT business analyst, tester, or developer, you are well prepped for IT project management. I began my career in QA, and my experience in testing has been invaluable to my role as an IT project manager.

The reason people in these roles make good IT project managers is because they are battle tested. They know what it’s like to be in the trenches of IT projects, and to come out on the other side.

Let’s face it, delivering IT projects is tough. Business executives often don’t realize how tough it is. They are like patrons in a restaurant ordering a four-course meal. As they sit in the dining hall waiting for their meal, agitated by any delay, they don’t see the chaos in the kitchen.

It’s the job of the IT project manager to manage the chaos while portraying calmness and confidence to the team and business. Managing the chaos and leading the project to completion is what makes the IT project manager so valuable.

For me, I enjoy the chaos that comes with delivering IT projects. I particularly like the areas of development and testing. If you love technology, working with others, and solving complex problems, the IT project manager role may be a great fit.

So although the identity of the IT project manager is hard to define, it’s an exciting time for the field. With the rapid advancement in technology and globalization, the demand for good IT project managers will continue to go up.

We have only begun to scratch the surface of the digital world. AI, IoT, and big data technologies are in their infancy. As we chart a course into unknown territories of the digital world, we need good IT project managers to lead the way!

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master.

Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

Is your project worth the investment?

return on investment

Return on investment, or ROI, is a term you often here in the corporate world. ROI is not an actual financial metric, like ROA (Return on Assets). When you are talking about ROI, you want to know how much you will get back if you invest in something.

If an athlete invests a lot of time in the gym he will most likely perform better in his sport, which is the return. It’s the same with business. Companies invest in a new product, piece of equipment or project only if they expect a good ROI.

They spend cash they have now in hopes of realizing a return at some future date.

Sometimes managers have to fight with competing projects to receive funding for their project. If they can forecast a good ROI it will help them get the funding.

To determine ROI, you need to understand the time value of money. Over time the value of a dollar one year from now will be less than it is today. Three concepts used in analyzing investments are future value, present value, and required rate of return.

Future Value

Future value is what a given amount of cash will be worth in the future if it is loaned out or invested. Being able to predict the future value, especially for security investors, is crucial.  It can tell you whether your investment is a good one. If a stock is selling for $200.00 and is estimated to increase 20% over the next year, the future value of the stock in one year would be $240.00

Present Value

Present value is the opposite of future value. If the future value is worth $240.00 in 1 year with a 20% interest rate or increase, then the current value is $200.00

Required Rate of Return

If an investments value expects to increase 20% in three years, the increase percentage is rate of return. Before making an investment decision, investors will have determined a required rate of return. Say if a rate of return is only 3% over the next three years the decision might be to not make the investment.

Calculating ROI

The fancy term investors use when putting a value on a company is DCF (discounted cash flow analysis). For now, let’s look at the three popular methods for calculating ROI. These can be used to forecast a projects ROI. They are the Payback Method, Net Present Value method, and the Internal Rate of return method. The payback method is a simple calculation to determine how long it will take to get back the original investment. The Net Present Value method is more complicated but also more powerful because if factors in the time value of money. Net Present Value is the present value minus the initial cash outlay. The Internal Rate of Return (IRR) method is like except it calculates the actual return provided by projected cash flows.

For more content like this, subscribe to the MacIsaac Consulting Blog.

Follow Mike on Twitter @MikeMacIsaac

To contact us about our services, click here.

Why Cash is King

Cash Flow

If you work in technology like me, you may not think there’s a need to focus much on finance. It is important though to understand the numbers, especially in project management.  In my next several blog posts I’m going to focus on financial management. To begin, let’s start with the green hard stuff, cash.

When it comes to cash and business, there are three things to know. The first is that cash is not the same as profit. The second is that most companies fail due to a shortage of cash flow. The third is that the cash statement provides valuable insight into a company’s situation. That last point is particularly important if you are planning to buy stock in a company. Warren Buffet might be the world’s greatest investor because he understands cash.

Cash is not the same as profit

Profit is the amount of revenue generated minus all expenses, what you have left is profit. So what is the difference between cash and profit? First cash doesn’t reflect money coming in through earned operating income. The cash may be coming in through loans or investors and that money doesn’t show up on an income statement.

Money from recorded profits isn’t received until some time after the transaction takes place. In an all cash transactions the funds will placed directly into the sellers account.  Small companies that are growing and creating profit, but not receiving the cash needed to keep up with expenses, run into trouble. This leads to the next topic which is that most companies fail due to a shortage of cash flow.

Most companies fail due to a shortage of cash flow

Profitable companies can go out of business if they don’t have enough cash. What happens is that they are continually waiting to receive cash to keep up with their expenses. An example would be as follows: Company A is a startup which over its first several months of business has recorded good revenue gains and large profits. The transactions for the products the company sells take 4-6 weeks for the funds to arrive. Due to the delay in receiving payments, the company does not have enough cash in the bank to cover the costs of operating expenses and growth. This ends up being a continual game of catch up with the actual cash behind the recorded profit. For most companies and startups it won’t be sustainable.

By reviewing a cash statement you can gain valuable insight into a company’s situation and where it might be headed

Income statements are complex and can be deceptive. The numbers can be manipulated by accountants to appear as though company is in better shape than it actually is. Most of the expenses on the statement haven’t been paid during the time of the statement.

Cash statements give an accurate view of how much cash was received and paid within a certain period. The cash flow statement can not be altered by the accountants like the income statement can be. Due to this, the cash statement gives great insights to investors because it paints a clear picture of how the company is doing.

In a sense the cash flow statement is a way of looking into a company’s bank account. The cash flow statement can provide valuable insight into a company’s future. If investment money is coming in, that may be an optimistic sign for the future. It could also mean that the company is selling stock to stay afloat. Looking at the cash flow statement may generate questions, but they are the right ones to be asking.

For more content like this, subscribe to the MacIsaac Consulting Blog.

Follow Mike on Twitter @MikeMacIsaac

To contact us about our services, click here.

Ready, Fire, Aim! Why we need to slow down when tackling complex issues

Leading technology projects

Leading technology projects, I’m often reminded that we need to slow down when tackling complex issues.

When faced with a problem, the tendency for most of us is to immediately act and do what our gut tells us. I call this the ready, fire, aim syndrome. Have you ever worked for a manager who had the team charge down a course of action only to realize after the fact it was a giant mistake? It’s not a good feeling and if you work in business and technology, I’m sure you’ve been there.

Here’s the key, although our instincts may be in the right place, it makes sense to slow down. When we slow down we can then think things through and look at the problem from different angles. Then, we can apply the action that will bring about the best solution.

Slowing down also enables us to get feedback from others. Sometimes there’s nothing more helpful than bringing in a fresh set of eyes for a different perspective and possible solution.

So the next time you’re ready to charge off into the battle, maybe take a step back and pause. Have you thought things through and engaged the right people? Is there even a need to act right away? Amazing things can happen when we sit still for a moment.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

System integration testing, a 6 step survival guide

system integration testing

So you’ve gotten through your planning, design, development and application testing. Everything looks good, the team feels confident, and the project is on track. There’s only one problem. Up until this point you’ve been looking at your code changes with tunnel vision. Application testing is like fixing a bike tire while it’s not connected to the bike. The real testing begins when the wheel gets reconnected to the bike. Once reconnected, then you’ll see the how the fixed tire works with all other parts of the bike.

I’ve been through many large software projects, both as a project manager and as a tester. Often the most difficult part of completing a software project is end to end system integration testing. This is particularly true if you’re not using an Agile model.

System integration testing is where the rubber meets the road. If you work for companies like Facebook, Spotify, or Twitter you are lucky. These companies use modern Agile software delivery methods that make integration testing less painful. Automation, DevOps, and continuous delivery is the way of the future.

Unfortunately most companies still build software the old fashion way. They create one huge pile of software then throw it over the fence to QA nearing project end. This leaves integration testing only a matter of weeks to complete and meet a tight deadline.

If you don’t do a great job planning for integration testing, you’ll be in for real trouble. If you do a great job planning, you’ll still most likely be in for some pain.

Here are 6 steps to help you survive system integration testing so you can be successful.

  1. Plan enough contingency time – This might be the most important point. Give the team enough time to do the test effort. If you know it takes 1-2 weeks just to get your environment and data working right, plan for that time. In system integration testing, many roadblocks occur. Data, configuration and environment issues can  block testing. Plan for the unexpected.
  2. Create test scenarios with the help of system experts – Once you know all the affected systems, find out who the technical experts are for each system. Then schedule white board meetings to draw out end to end flow test scenarios. The system experts will be invaluable helping you to write end to end scenarios.
  3. Get all your data setup in advance – There’s nothing more frustrating than finding out none of your data works on day 1 of testing. Setup your data in advance and check to see its setup right before you do your testing.
  4. Run connectivity tests – For large projects, take at least 1 week to test environment connections before the start of your SIT. Often companies use shared testing environments and configurations are always being changed. Make sure all your configurations and connections are setup. If you don’t do this, you’ll think you’re running into defects only to discover an application is pointing to the wrong environment.
  5. Use a war room – All throughout system integration testing you should have a room where all key resources sit together, all day. The key players usually consist of developers, testers, a PM, and system and environment experts. As soon as a test runs into an issue, a developer should be there to look into it immediately.
  6. Have a test lead manage the effort – Last but not least is having a good test lead. In my opinion, test leads have one of the most difficult jobs when it comes to managing integration testing. The job requires both testing expertise, project management skills, and tremendous grit. Often test leads have a lot of pressure put on them to meet deadlines. A good test lead will rise to the challenge.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

Leadership and tremendous discipline. What’s your 20 mile march?

project leadership

In Jim Collins book, Great By Choice, he sought out to answer the question, why do some companies thrive in uncertainty and chaos while others do not? He and his team performed extensive research to answer this question and they were able to draw some surprising conclusions. They referred to companies that thrived as 10X companies. These companies performed ten times greater than similar companies in their industry.

One of the factors of the 10X companies was that they were fanatically disciplined. They stuck to their strategy that aligned with their mission. While other companies in their industries made risky changes to adjust to the conditions, the 10X companies did not.

A great example of fanatical discipline is the 20 mile march. Collins tells the story of two teams that made a journey in 1911 to the South Pole, one led by Ronald Amundsen, the other by Robert Scott. In this story, Amundsen’s team was successful while Scott’s team failed (all perished).

One of the key differences between the teams was that Amundsen’s team stuck to a 20 mile marching regiment each day. Even through the most brutal weather conditions, they continued to march. They were fanatically disciplined!

The concept of 20 mile march resonates with me as a technical project leader. Whether I’m working on a traditional or Agile project, I’ve seen how important it is to stay disciplined. For Agile projects this means continuing to always have your ceremonies, maintain velocity and hold each other accountable.  In a more waterfall style project, it means continuing to drive towards your milestones and stick to the plan.

So what’s your 20 mile march? Are you providing the leadership to help your teams stay disciplined?

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

 

Start your projects right by focusing on relationships and momentum

As a project manager, it’s important that you start off your new projects the right way. Sometimes you may get a brand new project , other times you may need to take over a project that’s already in flight or has stalled. Either way, there a few recommendations I have to get the ball rolling.

First, focus on relationships and getting the inside scoop. Find out who the key resources and stakeholders are, then talk to them. Talk to them in a comfortable atmosphere so they can relax and give you their honest insight. This is where you will find out what type of project you are dealing with. You’ll discover the good, bad and the ugly. You won’t get this information in formal project meetings. You will also get to know your stakeholders and build trust, which is critical.

Next, focus on building momentum. You start to build momentum when you take action and create a sense of urgency. Set up your project meetings, schedule a kickoff and communicate status to all stakeholders. The key here is communication. Communicate often, the more the better! Update your stakeholders via email, in person updates, and status files. Under communication is a common mistake project managers make. If you bump into a stakeholder in the hall, they should know exactly the state of the project. They should feel the momentum.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

Quality control – Metrics are important but they don’t improve quality

Quality control, defined by the 5th edition PMBOK, is “The process of monitoring and recording results of executing the quality activities to assess performance and recommend necessary changes.” Quality control is important and valuable, especially for IT projects. Managers need to have a clear understanding of where things stand.  If your project is nearing deployment, you would want to know if any critical defects were still open or if any tests remained.

Quality control

Here’s the problem, a lot of organizations mistake quality control as quality improvement. Metrics are just like a thermometer. A thermometer can tell you the temperature, but it cannot change the temperature. Managers love to look at metrics and graphs, only to put more pressure on teams when they don’t like what they see.

I used to generate a defect slip rate report each month for management. The defect slip rate was calculated by dividing the number of defects found in production by the total number of defects found in prod and test. We defined a target of 20% so anytime we are over 20%, our slip rate was over our targeted threshold.

While the defect slip rate report helped give us a view into our software quality, it never improved it. Throughout the year the defect slip rate percentage on average would stay about the same.

When it comes to quality, organizations not only need to measure, they need to improve. This is part of the reason Agile and Scrum have become so popular for technology delivery. Using Scrum, project teams perform retrospectives, always looking for ways to improve.

The continuous improvement process goes back to the Toyota Production System and Deming’s Plan Do Check Act model. In Japan, the continuous improvement philosophy is called Kaizen.

The point is this, metrics are important, but what’s more important is improving quality. If you’re stuck in a pattern of putting out fires, you’re not improving quality. Fixing production issues is not improving quality. Running defect and metrics reports is not improving quality. Quality comes from improving the system as a whole, and building a quality product up front.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

Managing projects in a global operating environment

managing projects

Project managers need to be culturally versed to work in the global economy. Being open to learning new cultures helps foster good relationships. One way to do this is by developing cultural intelligence (CQ). “Cultural intelligence refers to a person’s ability to use reasoning and observation skills to interpret unfamiliar gestures and situations and devise appropriate behavioral responses.” (Daft, 2011)

The three components that work together for CQ are cognitive, emotional, and physical. Cognitive refers to your ability to pick up on observations. Emotional refers to self-motivation. Physical is being able to shift your body language or way of expressing yourself to align with people for a different culture.

Having the opportunity to work or study abroad and get exposed to different cultures is a great way to develop CQ. Studies have found that people who adapt to global management best are those who have grown up learning how to understand, empathize, and work with others from different cultures.

As a project manager, I work with people from other countries outside the US. My teams use technology to communicate with coworkers in other countries. Video conferences and internet connection forums have introduced great methods for work collaboration.

Whether you are talking over the phone or in person, it is important to show interest in cultures outside of your own.  This helps to establish good relationships and increases communication and team effectiveness. Relationships are the key to global business. Whether you are from Ireland, Japan, or America, you have to treat people well. People deserve to be treated with respect and dignity.

By developing cultural intelligence, you can manage projects successfully on a global scale.

For more on global effects on project management, see my LinkedIn post here.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

References

Daft, Richard L. (1996). The Leadership Experience

Page 2 of 3

Powered by WordPress & Theme by Anders Norén