If someone were to ask me what I think is the number one problem facing IT today, I’d say it was the inability to say “no”. Not specifications, not offshoring, not lack of technical talent, not lack of jobs, and not any single type of project methodology.
The reason IT exists is to provide value, in the form of software and/or hardware to
Our clients communicate what they want in a variety of ways. In some companies, this is done through marketing reps, analyses, and surveys. In many companies, it is the BA (Business Analyst) that interviews, interprets, and documents what is desired by the end user. In other companies, the Project Manager (PM) works directly with the client.
In all cases, regardless of project methodology, there is a strong tendency to give the end user whatever they want, and to do it ASAP. Many of the above personnel are evaluated on how happy they make the end user.
What we end up developing for ourselves are clients that act like spoiled children. Because we have given them everything they want, whenever they want it, they expect that type of responsiveness every single time. We do not educate our end users and although we knock ourselves out to understand what they do, how they do it, and what they want and “like” about a product, we do not ever allow them to become more technically sophisticated and understand what it is WE do, how we do it, and the impact change has on a product and that product’s schedule. We do not force our clients to look at project schedules and make hard choices. They want it all, and we try to give it to them, regardless of the impact to budgets, schedules, quality, and our people. One person telling a client they can get an enhancement into a migration that is only a week away can cause 12 people to have to work 80 hour weeks for several weeks, negatively impact the work they were already doing for that migration, and make the work they were doing for the NEXT migration late. And from a QA/QC perspective, it’s likely that all of it will be buggier.
The desire to give the client whatever they want, whenever they want it, also fails to develop talented PM, marketing, and BA staff that support their own organization. They never learn to really interview the client up-front, negotiate, and in their desire to please the customer, they screw over the IT organization, which SHOULD be pretty high on their priority list. The effect of unbridled change on a project schedule is usually that the timeframes get crushed to the point where the final product has either significantly less quality or that features end up being cut. That means that the ultimate goal – to please the client – ends up being negatively impacted ANYWAY. The effect on internal personnel is that an environment where OT is a constant energy drain may become normal and that nothing ever really becomes “finished”. Those are rarely motivators to the staff and can feed dissatisfaction and staff turnover.
Often a product may become over-designed for a first deployment, offering way too many bells and whistles that don’t work quite right yet, or full of features that handle exceptions that might occur once a year for one client, rather than focusing on functionality used by a majority of clients every day.
Technically speaking, quick, klugey “bandaids” may be developed rather than “doing it the right way”, due to time constraints. Over time, this results in applications that cannot be maintained and require a complete rewrite.
While I have rarely met a PM or BA capable of either successfully negotiating schedule dates or tactfully educating a client and letting them know their latest changes cannot be accommodated, the reverse has actually been true with some areas, particularly QA. I know some QA areas that were actually DISSOLVED by upper management because they said no to everything. I train my staff to look at every option and to make every attempt to accommodate a change or request; we rarely say “no”, but when we do, our “no” actually means “no”. We do not attempt or suggest a given change NOT go into production, but if we don’t have the manpower to test it, the responsibility for testing tasks goes back to the PM and they have to find other members of the team (usually developers) to perform the testing. Is that risky? Yes. But the point I’m trying to make here is that there is a limit to what can be supported by any group, and when you hit that limit, you need to say “no”.
I believe PMs and BAs need training in negotiation; both should never commit to dates with end users until they have checked with their teams and ensured a given change/enhancement can be accommodated without negatively impacting current schedules and WITHOUT HEROICS. Heroics are a fine thing – on occasion. Constant heroics burn out your team. I believe that often these resources forget one of the most important rules of “owning” a team. The rule is “protect your team members”. The end users already have managers, etc. protecting their interests. Your job is to represent and protect the interests of your OWN team during the negotiation process. When the negotiation process is performed properly, everyone “wins”. The end user is happy with/understands the decisions, and the project team can provide a high-quality product on time, within budget, and without killing their team members.
End users need to be educated and understand that when they ask for X, it impacts Y and Z and that no, they can’t have everything they want immediately. They need to be willing and able to examine options and choose those that provide the most benefit to their own needs, recognizing they will get everything they want, but in a prioritized order over time. Overall, they need to be part of the team and understand the work of the team, rather than just function as an outside, uncontrolled impactor of the team.
I fully understand that some “emergency” changes always occur during a project. Often these changes are absolutely necessary. They need to be incorporated. Adding to that a large number of less important changes in the spirit of “cooperation”, when you know it’s going to create a huge amount of work that will be difficult or close to impossible to handle, is merely throwing your own staff under the bus so you can earn some points with a client. And ultimately, it does not benefit anyone – including your client. So why do it? Even agile projects, which are more forgiving of and actually expect user change/enhancements, normally have a start and end date, with some sort of goal. And to be run correctly, they have to constantly prioritize and shift around workloads. Good agile projects do that with the end user as an active team member. Even then, you can end up working on a project that never ends if the enhancement/change requests never stop. If you’re a consultant being paid by the hour, that’s not necessarily a bad thing. For the rest of us, it’s akin to Living Hell.
Resources have to be empowered to say “no” when something is truly outside their ability to provide in a given timeframe. Often they are afraid to do so, and will therefore produce “something” within the timeframe. That “something” will usually end up being substandard. PMs and BAs need to learn not to commit to anything without first ensuring the work can be done, and they need to be trained to both interview adequately at the onset of a project to get as many business requirements as possible up-front, and to negotiate fixes/enhancements intelligently to ensure the entire team, both IT and end user, get the maximum benefit from the resources, time, and money available.
So are you “too easy”? It’s not too late to grow a spine, Mr. Loopner. Accept that the health and well-being of your team is as important as pleasing the client and that you are responsible for negotiating workable solutions that benefit both sides of the equation.
Posts
0 comments:
Post a Comment