Talent Development Centre

Tag Archives: project management

All Talent Development Centre posts for Canadian technology contractors relating to project management.

Plane Lands Safely at Airport!

David O'Brien By David O’Brien,
Vice President, East Region & Government Services at Eagle

Plane Lands Safely at Airport! The complex IT projects we don't always hear aboutBoth the IT community and the Federal Government often bemoan the fact that newspapers and media, in general, feast on failed technology programs and projects as their headline stories, while the successful projects are all but ignored. It is why the politicians and senior government executives have a long standing fear and largely prefer blind ignorance to the role technology can play in transforming and increasing productivity while they know it to be a truism. It’s why the Harper government, and frankly every government, effectively slows down or stops all IT projects in the months and sometimes year or two before elections to avoid potential embarrassments. We’re equally confident that although the media doesn’t report “Plane Lands Safely at Airport,” failed or over budget IT programs in the Federal Government tend to grab the headlines.

One needs only look at the incredible visibility the Phoenix pay system has garnered due to its glorious “failure”. This, of course, is the system that has resulted in 80,000 of 300,000 public servants not being paid correctly or in many cases at all. While it’s not ours to assign who, what or where all is to blame or at fault, let’s look at just some of the moving parts and complicating factors that have resulted in the new government fully engulfed in an IT Project mess that dominates the headlines. Unfortunately, many of these are characteristic and common to many projects and what therefore tend make it far more complicated than just the technology.

Processes. A long and convoluted procurement process that started in 2009 was awarded in 2011, and has now spanned two distinctly different governments. These procurements, although complex, tend to never envision total scope, underlying fundamental complexities already embedded, or difficulty to implement without a huge change management piece. For example, in this case, during the course of the software development work, it became clear that the myriad of union contracts in the Feds were being interpreted vastly differently by payroll specialists in the various regions and departments; furthermore, contract terms weren’t even clear. Re-configuring and “customizing” off-the-shelf software to handle many of the 80,000 pay rules and rates of the Feds is hopeful at best.

People. As always there is/was a huge people piece. The Phoenix implementation involved a government initiative that saw the Feds centralize and move its pay centre and all its pay specialists to Miramachi, New Brunswick; however, as is often the case, many of the experienced and tenured specialists chose not to move and a lot of knowledge capital went out the door (many have since been rehired and are located in Gatineau now). There has been a steep learning curve for many of the new hires as a result that resulted in a huge backlog of case files. Training and specifically training users was, and is, a vastly underestimated component

Specifications. It is now apparent that architects on the Feds initially vastly underestimated both data volumes and users for the new system, resulting in poor and sluggish performance of the system. Vendors and clients can certainly attest to so called post award “‘surprises” after what may have been a seemingly thorough RFI or RFP process. Who is to blame is always contentious but it is almost always real.

Finally there is always the unexpected, (somehow one thinks this should have been anticipated); however, in this case, the curve was the location of the Miramichi Pay Centre evidently had insufficient Internet bandwidth to handle the system load!

All to say that just as we know the hundreds of truly successful, on time and under budget IT projects will never be the lead story on the nightly news, we have to always remember every project is a complex amalgam of people, process, “stuff” and finally at the end, technology.

What You Need to Know About Agile Certification

Colin Montgomery By Colin Montgomery,
Director, Private Sector Services

Much of my day is spent discussing trends in the IT industry with clients and people in our resource network.  The hot topic these days is Agile ceWhat You Need to Know About Agile Certificationrtification. “Which certification is best and what is the value of certifications” tend to be the questions I’m asked.

While it’s beyond my scope to judge the value of the certifications themselves, from a staffing perspective, I can comment on some trends I see emerging.

First off, some type of Agile certification has value for anyone, including people who work on the business side of an organization which has adopted Agile who may only occasionally interact with IT.   Through the analysis phase of a technology project there is inevitably interaction between business and technology.  There is value in those who embrace and participate in the increased speed to market that the Agile process can contribute to and there is value in those who bridge the chasm that often exists between business and technology.

Program and Project Managers also ask me if they should get certified and my answer is a definite “yes”.   While you may no longer be close to the software development or network integration process, the assumption is that you will be providing some oversight to those processes and if they are being completed within the Agile framework then you should know the language and cycles of that process.  If you are a senior individual who has worked with the waterfall methodology for years, then your new-found knowledge of the Agile processes can help contribute to a project delivery framework that uses both where appropriate, for example. From an even simpler perspective, many of the PM roles we work on require some kind of Agile certification so in this world of key-word searches, you should have something on there.

As I mentioned earlier, while it is beyond my scope to comment on the value of specific certifications, I do suggest that anyone in IT realm should get some kind of baseline Agile certification as soon as they can especially if you anticipate entering the job market soon.

CSM (Certified Scrum Master) appears to be the most prevalent and would likely be used as a common term for keyword searches.  My understanding is that the CSM requires around 16 hours of course work and a multiple choice test that takes about an hour.

Another certification that is generating a lot of discussion is the PMI-ACP(Agile Certified Practitioner).  It requires more time and effort but seems to be emerging as a strong preference for those leading technology projects.

The discussions I’m having these days around Agile certification remind me a lot of the conversations I had a few years ago regarding PMP certification and I’m saying the same thing to those who are reluctant that I did back then.  It’s not going anywhere so you might as well get on board or risk being left behind.

Project Management is for Everyone (Infographic)

A number of the Talent Development Centre’s subscribers are Project Managers and spend a large amount of their time working with teams made up of both contractors and their clients’ full-time employees. While they’re hired for the oversite of the project, most will still agree that everybody on the team should have at least some knowledge and skills in Project Management. Unfortunately, that is not always the case.

Take a look at this infographic from Wrike. It finds that while almost everybody manages projects at some point in their regular job, few people use a standard approach and the results can lead to extra stress. If you’re a Project Manager, or any team member who believes this area could use some improvement, arm yourself with these facts next time you make the argument to your client.

Everyone's a Project Manager, But Not Everyone Can Manage Projects (#Infographic)
Infographic brought to you by Wrike

Humour at Work (Video)

For many of us, the holiday break is over and it’s time to get back to work. Along with colder weather, projects are waiting, work is piling up, and there’s not much positive energy coming from those around you. If this sounds familiar, then try being the person who brings a smile back to your team’s faces.

When appropriate, humour in your professional life can make a huge difference to your day and those around you. For inspiration, watch this TEDx Talks video where Andrew Tarvin speaks to some students at Ohio State University.

Agile Planning in a Nutshell

By Mishkin Berteig
President, Co-Founder of Berteig Consulting

Talent Development Centre subscribers can get 25% off Agile training! Visit www.worldmindware.com and use promocode EPR-25-CSM-MV4A for Certified ScrumMaster courses and promocode EPR-25-CSPO-QE7X for Certified Scrum Product Owner courses.

This post was originally posted on the Agile Advice Blog on August 21st, 2015.

Agile Planning in a NutshellAgile methods such as Scrum, Kanban and OpenAgile do not require long-term up-front plans.  However, many teams desire a long-term plan.  This can be thought of as a roadmap or schedule or a release plan.  Agile planning helps us build and maintain long-term plans.

Agile Planning Process

The steps to do this are actually very simple:

  1. Write down all the work to be done.  In Scrum these are called “Product Backlog Items”, in Kanban “Tasks” and in OpenAgile “Value Drivers”.
  2. Do some estimation of the work items.  Many Agile estimation techniques exist including Planning PokerThe Bucket System,Dot VotingT-Shirt Sizes.  These tools can be applied to many types of estimation.  There are three kinds of estimation that are important for Agile Planning:
    1. Estimating relative business value.  Usually done with the business people including customers and users.
    2. Estimating relative effort.  Usually done by the Agile team that will deliver the work.
    3. Estimating team capacity.  Also done by the Agile team (this is sometimes called “velocity”).
  3. Create the long-term plan.  Use the team capacity estimate and the sum of all the effort estimates to come up with an estimate of the overall time required to do the work.  (In Kanban, which doesn’t have an iterative approach, this is a bit more complicated.)  Use the business value and effort estimates to determine relative return on investment as a way to put work items in a logical sequence.

Agile planning allows a team to update estimates at any time.  Therefore, the techniques used above should not be thought of as a strict sequence.  Instead, as the team and the business people learn, the estimates and long-term plan can be easily updated.  Scrum refers to this ongoing process at “Product Backlog Refinement”.

Principles of Agile Planning

In order to use Agile planning effectively, people must be aware of and support the principles of Agile planning:

  1. Speed over accuracy.  We don’t want to waste time on planning!  Planning in and of itself does not deliver value.  Instead, get planning done fast and use the actual delivery of your Agile team to adjust plans as you go.
  2. Collaborative techniques.  We don’t want to be able to blame individuals if something goes wrong.  Instead, we create safe estimation and planning techniques.  Inevitably, when an estimate turns out to be wrong, it is impossible to blame a single individual for a “mistake”.
  3. Relative units.  We don’t try to estimate and plan based on “real” units such as dollars or hours.  Instead, we use ordering, relative estimation and other relative techniques to compare between options.  Humans are bad at estimating in absolute units.  We are much better at relative estimationand planning.

About the Author
Mishkin Berteig is the President and Co-Founder of Berteig Consulting Inc. He has been Mishkin Berteigtraining, coaching and consulting for organizations adopting Agile methods since 2001 and is committed to helping individuals, teams and organizations apply Agile methods. Mishkin is a Certified Scrum Trainer, and qualified to deliver OpenAgile and Agile Project Management training.  He has developed and delivered Agile training both in public and in-house seminars for over 3000 people in Canada and abroad. Courses have been as short as three hour intro-style and as long as five day boot-camp-style, and audiences have ranged from junior team members to senior executives. He has also assisted organizations of all sizes to make the transformation from traditional methods to Agile/Scrum methods (Extreme Programming, Scrum, Lean, OpenAgile).  Assistance includes Agile Engineering Practices, Agile teamwork, Agile project and product management, Agile management and executive management.

16 Top Project Management Methodologies (Infographic)

Project Management is anything but simple. To top it off, there’s a myriad of methodologies and acronyms to learn, which can be overwhelming for somebody new to the discipline. If you’re considering becoming a project manager but still trying to dissect your options, have a look at this infographic from Wrike. If you’re a seasoned project manager, let us know what you think. Do you have any preferences? Is anything missing?

”Project
Wrike Social Project Management Software

Keeping the End Goal in Mind… One Step at a Time

Frances McCart By Frances McCart,
Vice-President, Business Development at Eagle

Keeping the End Goal in Mind... One Step at a TimeIt is less than two weeks until I leave for my Kilimanjaro trek.  I posted in July about pushing one’s limits and thinking outside of what you would normally do, and being surprised at what can be accomplished.  I have been training for 9 months for the trek and have been busily preparing myself physically, mentally, and emotional for the adventure.  There has been a lot of planning and prep work and the greatest challenge still awaits me.

When thinking about the trek, and all the prep work, it gets overwhelming and easy to lose sight of the end goal.  You can get buried in all the details which start to seem daunting but what has kept me going is the end goal — to reach the summit safely and to raise funds for the Canadian Breast Cancer Foundation.

You don’t have to climb a mountain to apply this advice. When working on any intense project plan, the keys to the end success are identical:

  • Be well prepared and set goals. You don’t need to spend 9 months of intense training for your IT project, but you do need to be prepared with a detailed plan. My team has a complete itinerary detailing our climbing plan, including goals for each day and how long it should take to achieve them. Setting these milestones helps ensure success and keeps us from getting overwhelmed by the overall project.
  • Surround yourself with a great team. I’ve been training with an amazing group of people. We’re always encouraging each other in training, and I know that during our climb, we’ll continue to help each other up so we all reach the summit together. On top of this team, we’ll have an experienced leader we can trust to help us through the challenges and guide us up the mountain.
  • Keep climbing. Like every project you work on, as the trek gets tough, the only way to succeed will be to continue moving forward. A positive attitude, the support from that team, and determination to work through adversity will be crucial for me to reach the summit, and are critical elements to work through any complex project.
  • Keep the end goal in mind. Do you know the end goals of your project? Of course it has to be on time and on budget, but what else do you want to accomplish? As I said, my end goal is obviously to reach the summit, but I also want to get there safely and raise funds for the Canadian Breast Cancer Foundation. Identifying your intrinsic motivations that mean the most to you will help push through those times you think about slacking or giving up completely.
  • Celebrate your successes. After 7 days of grueling work, including a final 12-15 hour climb that starts at midnight, my team will be greeted at Millennium Camp with a nice beverage. In the following days, we’ll get the opportunity for more celebration, well-deserved spa time and a chance to explore the sights the region has to offer. How do you and your project team celebrate victories? Exploring Africa may be excessive, but dinner and drinks are a great way to wind down, focus on all of your accomplishments, and guarantee that you end on a positive note.

Every project, from climbing a mountain to developing software, will face set-backs. The key is to focus on the end goal and reach the summit one step at a time. That’s the strategy my team and I developed, and I invite you to use the same steps on all of your projects.

Please visit my page to support my trek and the Canadian Breast Cancer Foundation.

How to Handle Scope Creep: 5 Scripts You Can Use Now

This guest post by Justine Smith originally appeared on the Freshbooks Blog on July 16th, 2015

YHow to Handle Scope Creep: 5 Scripts You Can Use Nowou find yourself in the middle of a project, completely overwhelmed by the copious amount of client requests. It feels like you’re drowning, and the entire project is sinking along with you.

In the midst of your despair, there’s good news: you can stop it.

Most of the time, these feelings come from a sneaky little thing called scope creep. I can’t even begin to count the times it’s happened to me. And if you’re reading this article, then I’m sure I’m not the only one.

Today, I’m going to share five scripts that I’ve developed while struggling with scope creep. I’ve found that they’re very effective when explaining the situation to clients.

  1. Stay Vigilant from Day One

You’ve gotta learn how to outsmart scope creep.

As a project manager, I’ve got to handle scope creep at every turn. It requires saying yes or no as soon as a request comes in. Getting into this habit can feel pretty daunting at first.

In my freelancing days, scope creep really creeped me out. I’d just take on the bit of extra work in fear of losing the client if I said no. That’s a dangerous game to play, trust me. You’ll end up overworked by trying to accommodate dozens of small tasks that add up to a monstrous headache.

Next time a client sends a request and you need to say no, use this script:

“I’m sorry, but I’m not able to add in that feature/component/service based on the scope of this project. Would you like to setup a time to discuss expanding our project scope and budget to accommodate this new feature?”

  1. Offer Logical Solutions to the Problem

I’ve found that scope creep rarely happens in huge leaps. It’s the little requests here and there that add up. And clients will keep making requests until you say no. Can you really blame them? Who wouldn’t want to get every ounce of work they can for the money?

That’s why project management requires such diligence.

If you’re diligent, it may mean that you find yourself saying no more than you’d like. And if you’re anything like me, you hate saying no.

So, instead of a downright refusal, I oftentimes take a roundabout approach to scope creep. The approach looks something like this:

“Our current agreement is for [current terms] at [agreed cost]. From what you shared, you’d like to add [scope creep request]… I’d be willing to do that for [new cost based on additional request]. Or if that’s outside your budget, we can just stick to our original terms.”

  1. Always Refer Back to the Project Requirements

Now, this requires actually outlining project requirements in the beginning with your client. I’ve made the mistake of working without project requirements clearly documented. And it’s a mistake every time.

At the beginning of each project, I take time to clarify goals and objectives. This is the initial planning stage. And it saves me from a huge headache down the road.

It’s important that I balance my timeline, bandwidth and resources against the project’s complexity. This helps me define the functionality of specific deliverables. Deliverables get broken down into tasks and milestones.

Ultimately, this sets clear expectations of what I deliver in a project.

But despite my efforts to outline everything, scope creep still happens. And sometimes, it’s easiest to simply point clients to the documented project requirements. Here’s a script for that scenario:

“I’m happy that you’re so excited about what I’m doing that you want to add more. Unfortunately, what you’re asking goes outside of our original project requirements. I’ve attached them to this email for your convenience. Should we discuss expanding the budget and project requirements? I’d be happy to meet with you later this week.”

  1. Develop an Approval Process for Scope Change Requests

Like I said before, I’m not a huge fan of saying no. As a business professional, this made my life pretty difficult for a while. Some days I felt like the only word I used all day was no.

It left me feeling pretty discouraged.

And then I realized that I shouldn’t feel so much pressure about making this decision. In fact, I shouldn’t feel any pressure at all. Like every other aspect of the project, it’s my job to manage, not execute.

That’s when I realized the power of a project scope change management process. I don’t use it for every decision, because there are some things that require an easy yes or no. But I use this system when it comes to larger requests. And it works like a charm.

Now, a client or client manager comes to me with a scope change request. Instead of feeling the pressure of making a yes or no decision on the spot, I use something like this:

“Thanks for sharing this great idea. I can see why you’d like to add it into the project. Something of this magnitude needs to get the approval of our project sponsor, though. I’ll need to pitch the idea to him. Please shoot me an email back with the following information: the new capabilities/functionality, the business value of the change, and any consequences that could occur if we don’t make the change.”

  1. Protect Yourself from Gold Plating

Gold plating happens when you continue to work on a project or task, even though you’ve already met the outlined requirements. I’ve done this before, and it comes from a good place. But you shouldn’t keep working past the scope you’ve discussed with the client.

That’s right, scope creep doesn’t just come from clients. You and I can fall victim to it too.

I once worked with a marketing team that never had a dedicated project manager. It was up to the team to work together and get things done on time. As you can imagine, it became a nightmare.

But out of all the issues, gold plating caused the biggest issue. Developers ran wild making big promises outside the scope of the initial project. At the end of the day, the business took a turn for the worse. Why? Because the project wasn’t profitable due to the extra time spent gold plating.

If you run a team, you must teach them how to manage project scope. Here’s a simple script to combat a team member that’s easing into scope creep:

“Wow. It looks like you’ve been hard at work. I appreciate your diligence to this project, it’s very encouraging. Now, this may seem silly, but please don’t go above the call-of-duty too much. It’s important that we don’t stretch outside the bound of our initial project requirements. (If you haven’t seen them yet, I’ve attached the document for you.) Again, thanks for all your hard work. You rock.”

Those are five scope creep scripts you can use today. As project managers, freelancers and business owners, it’s important that we manage this important aspect of business.

What’s at the Heart of Project Management? (Infographic)

Thinking of moving into Project Management but wondering if it’s for you?  You’ve likely already worked on a number of projects and have an idea of what a Project Manager does, but do you really know what it’s about?  This infographic from Project Vibe covers everything involved in Project Management.  It will let you understand what you should learn about and how to prepare to ensure you make the best Project Manage possible. Take a look.  For all you Project Managers out there, is there anything you would add?

What's at the Heart of Project Management? (Infographic)

Measurements Towards Continuous Delivery

By Michael Bowler

The original version of this article can be found on the Agile Advice blog.

Talent Development Centre subscribers can get 25% off Agile training! Visit www.worldmindware.com and use promocode EPR-25-CSM-MV4A for Certified ScrumMaster courses and promocode EPR-25-CSPO-QE7X for Certified Scrum Product Owner courses.

Measurements Towards Continuous DeliveryI was asked yesterday what measurements a team could start to take to track their progress towards continuous delivery. Here are some initial thoughts.

Lead time per work item to production

Lead time starts the moment we have enough information that we could start the work (ie it’s “ready”). Most teams that measure lead time will stop the clock when that item reaches the teams definition of “done” which may or may not mean that the work is in production. In this case, we want to explicitly keep tracking the time until it really is in production.

Note that when we’re talking about continuous delivery, we make the distinction between deploy and release. Deploy is when we’ve pushed it to the production environment and release is when we turn it on. This measurement stops at the end of deploy.

Cycle time to “done”

If the lead time above is excessively long then we might want to track just cycle time. Cycle time starts when we begin working on the item and stops when we reach “done”.

When teams are first starting their journey to continuous delivery, lead times to production are often measured in months and it can be hard to get sufficient feedback with cycles that long. Measuring cycle time to “done” can be a good intermediate measurement while we work on reducing lead time to production.

Escaped defects

If a bug is discovered after the team said the work was done then we want to track that. Prior to hitting “done”, it’s not really a bug – it’s just unfinished work.

Shipping buggy code is bad and this should be obvious. Continuously delivering buggy code is worse. Let’s get the code in good shape before we start pushing deploys out regularly.

Defect fix times

How old is the oldest reported bug? I’ve seen teams that had bug lists that went on for pages and where the oldest were measured in years. Really successful teams fix bugs as fast as they appear.

Total regression test time

Track the total time it takes to do a full regression test. This includes both manual and automated tests. Teams that have primarily manual tests will measure this in weeks or months. Teams that have primarily automated tests will measure this in minutes or hours.

This is important because we would like to do a full regression test prior to any production deploy. Not doing that regression test introduces risk to the deployment. We can’t turn on continuous delivery if the risk is too high.

Time the build can be broken

How long can your continuous integration build be broken before it’s fixed? We all make mistakes. Sometimes something gets checked in that breaks the build. The question is how important is it to the team to get that build fixed? Does the team drop everything else to get it fixed or do they let it stay broken for days at a time?

Continuous delivery isn’t possible with a broken build.

Number of branches in version control

By the time you’ll be ready to turn on continuous delivery, you’ll only have one branch. Measuring how many you have now and tracking that over time will give you some indication of where you stand.

If your code isn’t in version control at all then stop taking measurements and just fix that one right now. I’m aware of teams in 2015 that still aren’t using version control and you’ll never get to continuous delivery that way.

Production outages during deployment

If your production deployments require taking the system offline then measure how much time it’s offline. If you achieve zero-downtime deploys then stop measuring this one.  Some applications such as batch processes may never require zero-downtime deploys. Interactive applications like webapps absolutely do.

I don’t suggest starting with everything at once. Pick one or two measurements and start there.

About Michael Bowler

Mike is an Agile and technical, coach and trainer who has been writing code for over thirty years and has been an active member of the Agile community for the last fifteen. He blends his strong technical background with a deep understanding of Agile methods to help teams consistently improve how they deliver value to their customers.