EPMGuidancehttp://www.epmguidance.com
Enterprise Project Management GuidanceMon, 11 Dec 2017 20:22:08 +0000en-UShourly1https://wordpress.org/?v=4.9.1http://www.epmguidance.com/wp-content/uploads/2016/01/cropped-Picture3-32x32.pngEPMGuidancehttp://www.epmguidance.com
323257886286EpmGuidancehttps://feedburner.google.comAvoiding a bad case of broken telephonehttp://feedproxy.google.com/~r/EpmGuidance/~3/3Z9NxlptiBo/
Wed, 22 Nov 2017 20:27:38 +0000http://www.epmguidance.com/?p=3533When we think of Project Managers we tend to think of communications as one of their key skills. I’ve spoken numerous times about the importance of communications in project management.

These days we tend to think of how connected we are. In the last 20 years, communications has evolved at an ever-increasing pace. We think nothing now of being connected 24×7 no matter where we are in the world. We are linked to the Internet from the phone on our hip, from the tablet in a purse, from a laptop in a bag or from one of many devices.

Even the availability of cell phone coverage is becoming less of a factor. For an upcoming hiking trip, I purchased a Satellite/GPS device that can exchange email or text messages no matter where on the planet I happen to be. The costs of such devices used to be prohibitive, but no longer.

We used to think of communications as speaking in person. Then voice-to-voice phone calls became commonplace. For business we marveled at the FAX machine and the impact it had on getting signed contracts. Email has now, of course, become a constant in our business and personal lives.

With all these new manners of communicating, project managers should be much more effective than ever before, shouldn’t they?

In some cases they are. Global communications has made some projects possible that we could have never thought of before. Project teams that are not co-located but instead span many time zones and even countries are now commonplace.

But is it always more effective?

Consider this question: “Where does communication happen?”

Does it happen in your mouth as you utter a sentence? Does it happen on your screen as you compose an email? Does it happen on your phone when you click Send on a text?

I don’t think so.

Communication always happens at the listener, not the speaker.

Oh yes, I understand that the listener wouldn’t have anything to listen to if it weren’t for the speaker but the only part of the communication worth measuring is where it arrives and is understood by the recipient.

Let’s say you get on a plane as a passenger and the intercom isn’t working just as happened to me once years ago in a rather small country. The flight attendant stands at the front of the aisle and starts the safety briefing in a low voice that only they can hear. Now I’ve flown some over my years and I’m pretty sure I could recite a complete safety briefing from memory but that day as they pulled out a lifejacket and mimicked putting it on, I became incredibly intent at what they were trying to communicate. For the flight attendant, they may have thought that they could hear it themselves, so – communication delivered. But it obviously was not.

In project management terms I’ve noticed an interested but disturbing trend among some project managers. It may have something to do with a new generation of project managers who are more used to digital communication than person-to-person or voice-to-voice so that the impact isn’t obvious but there are many project managers who have taken to using blogs, texts, collaboration messaging software or even social media to inform stakeholders without ensuring that their communications are being understood.

The result can be a mind-boggling disconnect. The project manager points to their communications plan and says “But I said I’d keep everyone up to date on our blog” and they have. But just uttering the communication or updating the dashboard or progressing the schedule is an insufficient structure for ensuring that communications occur.

We’ve had our own version of this in our technical support group.

“Is that issue for the client resolved?” I’ll ask.

“Yes,” replies one of our technical staff.

“Has the client confirmed that the fix we sent resolved the problem?” I’ll continue.

“Oh. Um, not yet,” they say. “I did send an email but they didn’t reply.”

“Well then the issue can’t be resolved,” I conclude. “Get on a voice-to-voice call and confirm.’

We’ve had to put structures in place to ensure that clients confirm that their problem is fixed and the same problem occurs with project management in many places.

Project managers have to guard that they don’t become a source or enabler of one-way project communications. As they make their plans for different types of communications and the myriad options of communication methods available over which to communicate, the most important principle to remember is this:

Communication happens at the listener, not the speaker.

]]>3533http://www.epmguidance.com/2017/11/22/avoiding-a-bad-case-of-broken-telephone/I’ll be speaking at the Cedar Rapids PMI on Oct 20http://feedproxy.google.com/~r/EpmGuidance/~3/0yG5qXPh_gU/
Tue, 17 Oct 2017 16:40:08 +0000http://www.epmguidance.com/?p=3525I’m very much looking forward to speaking at the Eastern Iowa chapter of the PMI in Cedar Rapids during their Professional Development Day event on Friday, October 20th. We’ll be talking about how to increase resource capacity; one of my favorite topics.

]]>3525http://www.epmguidance.com/2017/10/17/ill-be-speaking-at-the-cedar-rapids-pmi-on-oct-20/Multi-device, multi-platform development means no more monolithic thinkinghttp://feedproxy.google.com/~r/EpmGuidance/~3/yEKvNnTfj74/
Thu, 12 Oct 2017 15:37:31 +0000http://www.epmguidance.com/?p=3521My company, HMS Software, just released a brand new version of our keystone product, TimeControl. That’s great news of course and you can read all about it at HMS at: www.timecontrol.com/features/latest but what went into this development and release has our company thinking about development quite differently and so this post is more about how software development philosophies are evolving. It’s certainly a watershed moment for us.

TimeControl has been a browser-based product since 1999 which predates many companies in the software industry and certainly many companies with browser based products. For awhile TimeControl really only worked on Internet Explorer. Seven years ago we took pains to ensure that our product would work on multiple browsers and on multiple devices. We did testing on Internet Explorer of course but also on Firefox, Chrome, Safari and even Mozilla on Linux. For a few weeks I took great delight whenever I would wander into an Apple store to point the iPads and Macs I’d touch to the TimeControl demonstration URL. We were delighted to have expanded our view from the most prolific browser to support for many browsers.

We even made a mobile interface with a responsive design to allow browsers on different sized mobile devices to get access to the most common functionality of the timesheet system. But this was still through a browser. Yes, it was groundbreaking at the time, but it was still inside a single direction of development.

In the last 3 years, we’ve seen a critical mass of organizations and users shift their computing time to more software as a service and mobile devices. TimeControl is already available both as a purchased license for on-premise deployment and as a subscription service so I’ll save that part of the conversation for another day. The movement of computing to mobile SmartPhones and Tablets however is significant.

So, this month, as part of our new release of TimeControl, we released the TimeControl Mobile App. The development of the App over the last year came with plenty of design decisions. Should we write native code for Apple and Android separately? Should we use a hybrid design? Should we make the product work asynchronously or just like the browser version? How different should the interface be? Should we make some functionality that just works on the App?

Yet, through all of that conversation, until near the very end, most of us were thinking of the App as an extension of our existing development.

Now, with the App already published on both Google Play and the Apple App Store, we have decisions we’ve never considered.

Do we sell it or give it away? We decided quite some time ago not to charge for the App. We considered selling it as an additional feature or even using advertising to monetize the features. In the end, releasing it for free still means that clients have to own a license of TimeControl as the App only works when connected to TimeControl’s Server.

Should development of the App continue on an independent stream from the main product? The App is dependent on functionality available in the server itself of course, but what might we be able to do without updating the server? Or, should new features and improvements await the next major release of the server-based TimeControl?

It’s a quandary.

Many users, including myself, now wear a smart watch or other wearable technology. When something new like the TimeControl Mobile App come out, should I be expecting a watch version?

Maybe.

Users of Apps are less invested in these conversations than they’ve ever been. We have come to expect to look down at our phone and find the Apps we selected being updated with new features and better performance all the time. We expect to find an App that requires no training, no explanation, and no headaches. It is just supposed to “be”. It is at the developer level that we are expected to take all the complexity that used to be so present for the user away.

Software developers all over the world are considering these questions and it is an evolving marketplace. There is little room left for monolithic thinking that we build one big thing and people will use it once we explain how.

One thing is certain, there have been many changes in how we look at the software market and there will be more to come.

]]>3521http://www.epmguidance.com/2017/10/12/multi-device-multi-platform-development-means-no-more-monolithic-thinking/Dashboard Disastershttp://feedproxy.google.com/~r/EpmGuidance/~3/SdDrjX18iok/
Sun, 20 Aug 2017 15:15:58 +0000http://www.epmguidance.com/?p=3504We have an unnatural confidence in dashboards. When we see dashboard indicators we make all kinds of assumptions about them that may or not be true. But we depend on them all the same. This isn’t restricted to just project management dashboards though I have more experience with those than any others but dashboard indicators of all kinds.

Think about this. When you are driving and you see a green light, don’t you go through that intersection at full speed with complete confidence that it is safe to do so? Yet, only a couple of weeks ago, I watched someone do that very thing and miss being hit by a fire truck by only a few feet. He assumed complete confidence even though it’s possible to have emergency vehicles go through a red light from time to time.

While we’re talking about green lights, what else do we assume? We assume that the lights are working perfectly and that they haven’t chosen this moment in time to be green from all directions. We assume that no one will run the red light and hit us from the side. We assume that we are seeing all indicators.

If that’s so for driving to work, what about once we get there and we look at our real-time dashboard indicators of our projects or businesses? The same logic applies.

We look at a dashboard on our mobile device and make all kinds of assumptions. We see green and we know everything is fine. We assume that the indicator is up to date; in real-time in fact. We assume that it is complete; that all data is accounted for. We assume that someone somehow has approved the data; that is has been authorized for publication. We assume that the algorithm that is generating the indicator is not only accurate but that it has accounted perfectly for the display.

Yet, I’ve done a number of dashboard audits and found that indicators are often changed manually by the very people being measured. What is the incentive for these people to put a yellow or red indicator? There is none. “Might as well leave it green until I can get the project fixed,” they might think.

Even if the dashboard is working properly, would you make a decision about resource management if you didn’t know that you were looking at 100% of the data? Most dashboards don’t display the completeness or quality of the data. What if you were only looking at 80% of your projects and it didn’t look like you were overloaded. What might the incentive be of project managers of the hard-to-resource projects to make sure their data was up to date? There is none. “Better not to show how bad it is and just ask for more people,” they might think.

We also typically make another dashboard assumption that can cause real trouble. We assume that if an indicator is negative that someone must be doing something about it. But I’ve seen many organizations where that’s just not the case or where there is no structured response to a negative indicator. At McGill where I’ve taught Advanced Project Management in the past, we have used a real use-case IT study from one of the world’s leading aerospace manufacturers. Part of the data of this study shows the history of dashboard indicators from a large multi-month IT project. Several of the indicators are red for month after month and one question that is always asked is “What was done when these turned red?” The answer is, “nothing”. “We thought it would get better,” is the answer. That reaction isn’t unique. It could be true for almost anyone.

If you have a project or portfolio dashboard, here are a few tips on avoiding a dashboard disaster of your own:

Don’t measure too much
It’s easy to create a dashboard indicator but make sure it is measuring something that can leave the viewer empowered to take action of some kind.

Indicate the dashboard’s quality
Is the data complete? Is it timely? Does all the data displayed come from the same time period?

Have an action for each indicator
This may be the most important tip of all. For each dashboard indicator, have a structured response of what must be done and by whom if the indicator is green, yellow, red, or whatever type of indicator you use.

If you have an existing dashboard, then a regular audit of what data are the indicators being driven from and is the data still valid and is the dashboard still relevant is healthy. If you don’t see documented standards for how to act based on the dashboard indicator, then putting those in can be a powerful improvement for very little effort.

Simplest can be best. A dashboard isn’t just a pacifier. It should be something that enables decision making and, just like when the light turns red at the intersection, makes you hit the brakes to stay safe.

]]>3504http://www.epmguidance.com/2017/08/20/dashboard-disasters/We live in uncertain timeshttp://feedproxy.google.com/~r/EpmGuidance/~3/lIagGPEF98k/
Fri, 14 Jul 2017 00:51:25 +0000http://www.epmguidance.com/?p=3496I’m struck by the degree in recent times that our world is filled with uncertainty. Oh there has always been uncertainty. I know that. Control is an illusion but lately so many things that people have counted on have become uncertain.

Geo-Politics

In the geo-political sphere in the last few months we’ve seen big changes in the way the US Administration works. No matter which side of the American political divide you’re on, I doubt I can find a single person who can say things are more certain and less risky than they can remember. We’ve seen proposed changes in policies, actual changes in the way policies are applied and many changes that are expected or are already happening that are very different from how they have been in a generation or more. Even for those who say “Don’t worry. Everything will be mostly the same,” there is uncertainty. What will change? What will not? How might it affect my business; my family? We’re not sure.

If you’re thinking that my thoughts are tuned only to America, think again. In Canada, where my own HMS Software is based, there has also been a change in the Administration. The government has moved from right of center to left of center. The change is perhaps less dramatic but it is change nonetheless. And what does it portent? How will it affect the drivers of the Canadian economy? How will it affect my business, my project, my family?

In the United Kingdom, home of the stiff upper lip, things are also uncertain. Brexit? What does it mean? No one on earth currently knows. We know negotiations are underway but what will it mean for different types of businesses and even families? Will Britons in the EU have to move? Will EU families in Britain have to move? Can they stay? These are visceral decisions for millions as well as their children, spouses and other family members.

The EU is also in turmoil. What will the UK departing the EU mean in the end? Will the EU have to change? No one is certain. What about debt and currency issues that have been ongoing for years?

Project Managers

As a project manager and an entrepreneur, I’m familiar with uncertainty and risk. Indeed, it is the water I swim in every day.

Think about it. A project manager arrives to the first day on the project to find… Nothing.

There is no plan, no completed product, not even a team. On the first day of a project, it is almost pure risk. Yet the project manager must hold steady. They must guide the ship through those risky early times to a place where the project has a chance to succeed.

There will be risks realized in almost every project and certainly every project of significance but great project managers can often have those risks not even be noticed on the outside.

We tend to look back on a project at its completion and say, “Oh, sure. That was the plan all along!” The project manager will then often give a knowing smile and turn away. They know that’s not true but that is the mark of a project’s success. That at the end, all the moments of risk that the project manager faced seem to be historically transformed into mere challenges of the moment.

So what can you count on? How do you move forward?

People often ask me how one can function in this kind of economy and this kind of business environment. I tend to answer in the same way I would for any project I manage. I tend to take stock and focus on those things I can control rather than those I can’t. In our own business at HMS, we’ve been very fortunate over the last 30 years to build up a large and satisfied clientele so that is a focus we can always empower. We know that technology is evolving and fluid but we focus on the development we can get done rather than the work we can’t get to or that’s just impossible at the moment.

I’ve been delighted to see new businesses start up and start to thrive in industries I’d have never expected. I see new technology in social media and robotics that I could never have imagined ten years ago and different businesses have been able to adapt to take advantage of these new technologies in ways I’d have never expected. It’s growth in an aspect of my own industry that fascinates me. The entrepreneurial spirit is alive and well and, perhaps it is even encouraged by turmoil and risk.

HMS has been around a long time and that stability of having been around for 30+ years gives us some perspective. We know we can count on our people. We know that quality products ultimately prevail. We know that we can be counted on.

For some, thriving in uncertain times is a constant.

I’m certain to find that spirit in both entrepreneurs and project managers.

]]>3496http://www.epmguidance.com/2017/07/13/we-live-in-uncertain-times/Too eager to pleasehttp://feedproxy.google.com/~r/EpmGuidance/~3/Ytc4xPU0LFE/
Thu, 08 Jun 2017 16:00:02 +0000http://www.epmguidance.com/?p=3486Project Managers almost always find themselves in the middle of conflicting interests. On the one hand, marketing wants a project finished immediately. On the other hand engineering is going to need much, much more time than they’d ever imagined in order to get the project right. On the other hand, management wants to do the project with less money. On the other hand, sales needs new projects started for which there are no resources.

In the face of that kind of multi-faceted situation, the pressure to please is enormous but just trying to please every request is rarely a winning solution.

Let’s take a situation I live in my firm every day. Our own product, TimeControl, is a commercial-off-the-shelf (COTS) application. It has been used by thousands of firms and hundreds of thousands of users worldwide. Yet, on a weekly basis or so, one of our staff is asked for functionality that is not in the product.

For some organizations this would not be a problem but in our environment, our developers, technical support personnel and implementers all rotate rolls. We do this very deliberately as we find that programmers who have to support the code they wrote, tend to do better quality code and technical support people who go out into the field to deploy our software tend to be much better about seeing things from the client’s perspective and implementers who know the product at the code level can see how things work within the product intimately.

On the one hand, this tends to produce rave reviews from clients who always experience technical or implementation support as though it had already been escalated to the top level but on the other hand there is a distinct challenge that we have to deal with.

Our technical staff are all people-pleasers and, given they also develop, they have the skills and access to answer questions in a way that most implementers would not.

So, every few days we get a request from a client for functionality and our programmers are only too pleased to think about how to create it.

We have checks and balances around TimeControl to make sure that such requests or the desires of our eager-to-please technical staff won’t change the product with a change that hundreds of thousands of users might then have to deal with. We’ve been doing this for about thirty years now so it’s common ground for us, even if from time to time it frustrates our technical staff. The end result though is that HMS and TimeControl get the best of both worlds. But it’s a process that requires regular vigilance

Project Managers face this same challenge every day.

The marketing staff wants it sooner. So the eager-to-please project manager will feel enormous pressure to get engineering to get the project done faster.

Management will want to improve the bottom line so the eager-to-please project manager will look at how he or she can cut corners.

Engineering will want to give themselves more time to do more of the job they want to do. So the eager-to-please project manager will delay, obfuscate and misdirect to get them what they want.

It is likely that none of this will be productive in the overall scheme of things. Moreover, any project manager who encourages such discussion will soon find themselves at the nexus of misery as everyone involved will interact with them as though this is a zero-sum game. “If you give to that department, you have taken from mine!” The stress from this alone can be debilitating and I have seen project managers resign completely rather than face the growing upset of being pulled in different directions.

Project managers have a unique responsibility to carry a detached perspective. They must be looking from outside the morass of which department wants what to see what would be best for the organization overall. It is up to them to point out to the relevant stakeholders the trade-off for the requests they are making.

Yes, you can cut corners. But, how will that affect you negatively in the months and years to come?

Yes, you can do it faster, but will you end up with the result you need to be first to market and able to dominate it with that functionality?

Yes, you can make the ultimate mouse trap but will you damage the company by waiting for it and does anyone want to buy the atomic mousetrap?

I think Project managers have a responsibility to be the pivot point for all of those conversations because they all resolve themselves at the project manager’s desk. And, just like I have to do with TimeControl, the project manager has the tools to see the entire picture.

]]>3486http://www.epmguidance.com/2017/06/08/too-eager-to-please/Online or OnPremise Webinar serieshttp://feedproxy.google.com/~r/EpmGuidance/~3/2y46VrOkNe8/
Tue, 09 May 2017 16:43:33 +0000http://www.epmguidance.com/?p=3461You’ll find here the index of the webinar series OnLine or OnPremise which discusses the key elements of choosing between purchasing software for an on-premise installation vs. subscribing to software in the cloud. Each webinar is only 5-6 minutes long. You can watch the webinars in sequence if you prefer but they do not need to be seen in any particular order:

]]>3461http://www.epmguidance.com/2017/05/09/online-or-onpremise-webinar-series/Mismatched Expectationshttp://feedproxy.google.com/~r/EpmGuidance/~3/_m71iR_jl3s/
Fri, 14 Apr 2017 15:26:10 +0000http://www.epmguidance.com/?p=3443In today’s Agile-oriented software world, it’s all too tempting to skip the important steps of defining the work completely. There is no doubt that there is a meeting of minds between the client and the developers to end up with a product that fulfills the client’s desires and is of high quality and rapid arrival but once we get into the actual management of the project, there are differences in perspectives that are not obvious.

A client will make a request for a feature that they may be quite clear about but haven’t thought out all the implications of. In a perfect world, a Business Analyst would work through these requirements with the client in a user story to walk through how that feature should work and, hopefully, what happens after the feature works as they walk through the whole workflow.

The world is sadly not a perfect place.

Even when a BA is working on the project, we often see a feature request arrive to developers that describes the request adequately but does little to address the impact of the feature. The client’s perspective has usually shifted from “I have this business problem I need solved” to “This is the feature I’d like”. Those are two very different goals. The discussion becomes feature-centric.

The developer’s perspective is typically all about how to do something, not whether it should be done at all or if there is even an alternative to the feature.

In our office we have a checks and balances system that puts feature requests through a couple of people before they’re accepted and often results in the feature being delivered in a way that wasn’t originally anticipated but is much more effective or which avoids collateral damage to other aspects of the system that had never been originally thought out.

Still, even in my office, we end up with clients and our staff working at cross-purposes. Just like that old expression, “The road to hell is paved with good intentions,” these moments start off with good intentions.

The problems are almost always in a part of the project where change management is possible or during the user acceptance phase and the issue is wholly due to mismatched expectations.

The client, like all clients, wants a change. Perhaps they’ve now seen what they requested and on screen it looks very different from what they had anticipated. Perhaps the end-users hadn’t been fully included during the design and now that they are looking at the screens during testing, they not seeing the benefits of the new system. Perhaps the client just had an improved idea. Whatever the stimulus, the result is a request for something different and as is always the case, the pressure is on to deliver it right away.

Unlike during the design phase of a project when many resources are associated to reviewing and game-playing the work flow of a design, the request may seem innocuous but it is easy to have a tiny request become a major heartache.

With TimeControl, requests for changes from clients are usually able to be handled during the configuration of the software but even here we can have challenges. Making a key design decision about how long the timesheet period should be can have massive implications later. Should it be weekly, daily, bi-weekly, bi-monthly, monthly? We always take time to work through the implications of this as it affects how approvals, validations and workflow will work later but even here, we’ve had more than one client get through the deployment and then call to say, “I know we said weekly but could we switch to bi-weekly?” The answer to these things is often “Sure… but a bunch of your configuration will need to be redone.” In the end we wrote a whole white paper on the subject to give clients an easy vehicle to pass around all possible involved parties in the office for the discussion of that one implementation decision.

When our technical staff interact with our clients, they are always oriented around satisfying the client. That can cause heartache too. Sometimes it is best to say to the client, “I hear your request but before I say we should do it, let me walk through the implications of the request. Once you hear them you may change your mind.” However, if you’re someone who is all about satisfying your client, that’s not a sentence that is immediately thought of. Instead, and especially under pressure, a technical person might say. “I will do my best to do that right away,” not even pausing themselves to walk through the implications. Our own process catches most of these requests but some still slip through.

In the end, the best thing to think of when there are requests from a client to a developer, whether that happens during the bid phase, design phase or at any time later is to pause a moment and make sure that the thinking of both sides are on the same page.

A couple of key questions for the client to ask might be:

How much effort are we talking about?

What implications will this have on our data?

Are there any implications of this request that will impact any other part of our design?

How will we test this new feature to ensure it delivers exactly what we want?

Key questions for a developer might be:

What is the business challenge that you hope this feature will solve?

Are you clear that this is a change request that will affect the cost, schedule, testing of the project?

Have you walked through this request with other impacted parties on your side?

Have you considered how you will test this feature to make sure it doesn’t affect anything else in the system?

Is there a way you could fulfill this business requirement using other features or in another way?

What is the priority of this request compared to the others we are already working on?

Is there a completed design for this request that considers how it will fit into your existing workflow?

In the end, these questions just serve to have all parties pause for a moment and ensure that the perspective of both parties are aligned.

]]>3443http://www.epmguidance.com/2017/04/14/mismatched-expectations/There’s no cheese down that tunnel!http://feedproxy.google.com/~r/EpmGuidance/~3/vQ33_oWDT5g/
Tue, 28 Mar 2017 14:06:11 +0000http://www.epmguidance.com/?p=3420In my brief flirtation with Psychology in my first year of university, I learned more than I’d ever want to know about rats in a maze. My distaste for the exercise would come back to haunt me last year when my stepson needed a dwarf hamster for his science project. Wendy is now a part of the family. You can see Wendy and our home-made maze on the right.

You’ve no doubt seen the images I’m talking about. You put a piece of cheese that the mouse or hamster loves at one end of the maze and you drop him (or her) in at the other end and time them over and over and over and over again running through the maze to see if they can learn how to get to the cheese more quickly by avoiding wrong turns.

Then, when you know the poor animal has learned perfectly where the cheese is, you remove it.

The mouse or hamster will go back down that tunnel over and over again, certain that the cheese will be there next time.

The difference between humans and hamsters is that eventually the hamsters will quit.

We humans are, as a species, obstinate. If we think there’s a favorable result down that maze somewhere, we’ll keep going until we starve to death.

I’ve had a couple of projects that have been in this category for some time. One project involves the link with a piece of software from a vendor that we’ve worked with for decades. Some time ago, they released a new version of their software and suddenly the link we’d counted on for ages didn’t work properly. We asked the vendor if they knew what we should do and they didn’t and the developers who have worked on this have made a number of attempts to solve the broken link.

The problem is, that despite being brilliant developers (much smarter than myself), they have focused over and over on the one bit of code that throws an error. We know that error very well by now and no matter how many times we look at that one tiny bit of code, it won’t work. Oh they’ve tried getting to the reluctant command in different ways, some of them very clever but we’re still at a standstill. It’s the cheese-less tunnel for us.

This week I put the challenging project back on the books and told the staff to throw out all the legacy code for the module.

“Start from a blank page,” I said. “Your job is not to make that code work. We threw out the code. Your job is to solve our basic business challenge as though looking at it for the first time.”

The thinking on the project has already changed. Instead of working on the one command from this vendor’s product that isn’t working, we’re looking at all paths of movement of data from our system to theirs that results with data in the right place. It turns out there are quite a number of options which we’d never tried.

It’s not unusual in a project to head down one path, hit some barrier and then pause while you wait for the barrier to be resolved but the lesson for me in this project is that you can wait at a barrier too long before it makes more sense to back up and try some other route. In this case, closing down the path we’d been on for so long is forcing the developers to rethink the entire exercise laterally instead of literally.

I don’t actually care what the path to success is so long as we get there. That a particular method fails is less interesting to me than the end result of solving the business problem I started with.

Over the last few attempts, we’ve had reactions from our staff that want to place the blame on the other vendor, or the indignation that their software doesn’t work as documented or on the righteousness of our approach.

None of those gets us the cheese.

I’m quite optimistic now that we’ll finally solve this particular challenge. I’ll keep you all posted on our results.

]]>3420http://www.epmguidance.com/2017/03/28/theres-no-cheese-down-that-tunnel/Scope Creep in an Agile Worldhttp://feedproxy.google.com/~r/EpmGuidance/~3/4DSe24umm2U/
Tue, 21 Mar 2017 15:00:01 +0000http://www.epmguidance.com/?p=3416The whole concept of Agile was designed to prevent project bloat. Back in the 1990’s when software development and deployment projects became mega projects a little too easily, the notion of Agile became much more popular.

We’ve all heard about Agile. The idea that we’ll develop incrementally in sprints and after each sprint we should have deployable code, each time with a bit more functionality.

It’s a great idea.

We use Agile project management within our own development at HMS. Using this methodology we can take an elephant sized project and gradually consume it one bite at a time.

But to make this work, there are some assumptions in the background that you can’t lose sight of. We assume that as we’re eating the elephant, no one is substituting an additional, larger elephant each time we go to our list of things to do. In Agile, this list is called the backlog and we tend to think of the backlog as a constrained list.

But who in your organization is in charge of constraining it?

One of the great things about Agile is that it’s, well, agile. It allows the project to maneuver in different directions based on how the project evolves including how the users react to the early iterations of the code being released.

That’s awesome (really, it is), but this is just the formula that can result in the dreaded scope creep. As feedback arrives to push the functionality one way then the other, a few things become easy to forget about:

Who is doing the creeping?

Firstly, the very people giving feedback are probably the very people who helped with the original design. It’s not uncommon to have people respond in one way while a project is more theoretical and a very different way once they can see it. The budget for the project which is likely to have gone through a whole process of tradeoffs and prioritization is built around those theoretical decisions, not the more immediate reactions to things from the field as the project is actually underway even if the people who did that budgeting and the people who are making these new requests are the same people.

Is everyone still on the same page?

It is common to be more expansive in ensuring that a project has all the design requirements built into it when it’s first budgeted. Perhaps someone from Finance was tasked to ensure a particular link would work and that the data would have been validated in some way. Then someone from Payroll was tasked to review the design and make sure the payroll rules were followed. But as the project gets underway, it’s often difficult to ensure that all the people who worked diligently on the design at the beginning are still giving the project the same level of attention as it is being coded in an Agile methodology.

There’s not a single simple answer to how to avoid these types of pitfalls. But blissfully moving on in an Agile world without thinking about some of the constraints and assumptions that other aspects of the business are counting on can lead to problems.

Our experience has been to institute a few checks and balances to projects:

Communicate

First of all, communication is key and by communication, I mean discussion. We have seen projects where there was some upset at deployment and someone says “Oh that was in the June email last year” and, sure enough, there the change is, buried on page 12 of an email with many topics in it. So, we’ve come to do more discussion of requested changes before they end up in the backlog.

Estimate

Sometimes a request from the client or user will seem like a tiny impact in terms of developer hours but we have found some things that seemed easy to change in the code can cause enormous heartache in downstream processes and user impact. So, we ask that estimates include not just coding time but impact on QA both now and for future versions, upgradeability, backwards compatibility, documentation and future technical support. Often an original estimate of a few hours becomes days or weeks long when we shine a light on all the other work involved.

Corporate memory

We have had to take the responsibility of being the corporate memory on numerous projects. That’s often because our team is quite stable and client teams often change faster. So, even with lots of documentation and email threads and communications plans. We are often the ones who say “You might remember that the reason you said last year that you wanted to do this in this way was because of this.” Find someone who will be the anchor for the corporate memory.

Project Management Best Practices

Even while the Agile group is evolving the project in great strides, don’t abandon your basic project management principles. Did you have a budget? The project charter? Approved design? Progress milestones? They can be even more important at one level when Agile is involved at another.

Like all things, Agile has pluses and minuses. I always recommending taking from these methodologies the practices and processes that work for you in your particular environment. In most organizations I’ve worked with, this usually means an environment with processes culled from several different methodologies.