We're a free community of 7000+ Texas technology professionals here to network and promote our local tech scene.
If you're working in semiconductors, hardware, software, or IT in Texas, join us!
Teaching To The Test
Submitted by Jane Prusakova on Tue, 07/14/2009 - 10:02am.
::
When teachers' performance is measured by students' test results, interesting things happen. First of all, the learning disappears, and test preparation begins. Many teachers start to cheat, even if they never have before. Students get lots of practice in test-taking and even test-passing, but hardly gain much understanding of the subject matter.
Software projects are often judged by being on-time and on-budget. A project that stopped at a certain date is considered successful because the team made its deadline, and a project that required extra hardware is a failure because that extra server pushed it over the budget. As should be expected, when the pressure to make the deadline and stay within budget is high, projects and project teams behave just like the teachers teaching to the test.
It takes effort and craft to make a program into a lasting product - usable, stable, maintainable. But a project that is headed full-speed toward a deadline has no reason to produce products, it only needs to make things work by the deadline. A project that cares more about the budget than it does about quality chooses to "save" on hardware and software tools (not to mention people).
More importantly, a project that is measured by time and money does not have a way to measure value-added - and no reason to work on creating a real success measure. Just like the teachers and bureaucrats who do not know how to assess quality of teaching and learning, and attempt to substitute a multiple-choice quiz instead.
- Jane Prusakova's blog
- Login or register to post comments
Jane is right on the mark with an excellent bit of analogy by comparison and contrast.
While businesses and other organizations will always have budget and time-to-market constraints, leveraging those constraints to the level of god-like deities is just not the best approach for successful projects or high quality products.
Blogging on this topic last month (Defining Project Success) lead me to an interesting bit of research by Scott W. Ambler (of Agile and IBM Rational fame) published on the Dr. Dobbs website. Scott publishes poll results based on using five criteria for project success. Here's what respondents considered important.
Here's what I said about those results on enweave.
There is great emphasis from survey respondents on the condition of the final product as opposed to arbitrary milestones or deadlines. Does the product actually fill the (changing, evolving) needs of the customer when delivered? Is the product really ready for delivery or is this just meeting an arbitrary deadline with an unfinished product? Is the quality of the product at a level where it can be placed in users hands or on the market with confidence or does it require further refinement?
There is great emphasis from survey respondents on the condition of people as opposed to resource allocation, task assignments, or effort/hours. "The needs of people (stakeholders)", and "Mentally and physically healthy people." Products meet and are defined by people's needs and people create extraordinary products out of joy and passion; collaboration and understanding; mutual respect and teamwork.
Obviously it seems the real success criteria and priorities for project stakeholders lie in determining/defining the state of the final product and the state/condition of all the people involved -- stakeholders, users, team members, managers; everyone.
William W. (Woody) Williams
Project Management Consultant
| Blog | Twitter |
w3src Consulting
thanks for an interesting bit of research and links.
87.3% of respondents wanting to build a useful system seem rather low. What are the other 12.7% thinking? And what is their role in the organization undertaking the project?
It is rather striking that over 30% of professionals who chose to take part in Scott Ambler's (an Agile promoter and practitioner) believe that ROI is less important than being under an arbitrary and under-researched number that is budget.
And it is illuminating that nearly a quarter of participants do not care about the people doing the project.
The survey results were gathered before 2007, long before current recession took hold.
Jane Prusakova
Software Architect & Developer
My blog
There is some information about the role of survey respondents on page 3 of the Dobbs article.
There are follow-ups, more data, and more recent surveys on Scott's web site: http://www.ambysoft.com/surveys/
William W. (Woody) Williams
Project Management Consultant
| Blog | Twitter |
w3src Consulting
Great post Jane.
One note, where you said, "A project that cares more about the budget," I would substitute "project" for "client" or "client's agent".
A project is something that is internal to a software development agency. I think in the case of a product development company like Netflix, the team (the personification of the project) has some say in quality. They may have the opportunity to convince the client (usually a Business Analyst or an SME) that this or that should be done for quality.
For a consulting or contracting agency, the team producing the software only has one recourse if the client decides, "I don't care about quality." They can abandon the contract.
I think the problem comes when the person responsible for filling the customer role does not want to pass along bad news. They would rather save face and pass off the project as being done and "on-time", than admit that the project probably needs a little more time and money.
We live in a culture of blame, and no one wants to be the fall guy (or gal).
To me, all this concern about on-time and under-budget really stinks to me of what is wrong with American business. We are too focused on what we are getting , money, and not nearly focused enough on what we are giving, our services and products.
An anecdotal example, the other day I was on my way to Houston. I thought I'd had a map of where I was going pulled up on my laptop, turns out I'd closed that page. Oops. So I stopped at a Starbucks around Cy-Fair. Wifi at Starbucks used to be free. I'm not a total cheapskate, so I had every intention on going in there and buying a coffee while I pulled up Google Maps. A ten dollar gift card and two registration forms later, I was on their wifi. You see, in order to use the wifi, I had to have a "recently used" gift card, and the gift card has to have a minimum remaining balance of $5. So if I get up in the middle of my wifi session and get another minty mocha will AT&T cut me off?
Is all of that necessary? No. Does it negatively impact the quality of their service in my mind and the minds of others? Yes. Pretty stupid move for a company built on service.
Few people ask the intended recipient of a service or product, "Hey, is this ok? Do you need free wifi with that?"
My question is (to all the clients concerned primarily with budget out there): if you don't care about the people you provide a product or service to, why even bother starting a software project, and how much longer do you think you will stay in business?
There is and always will be concern around budget constraints for projects. ROI and other (many other) constraints may be more or less important at any given point in time including customer/client expectations and satisfaction.
Budget constraints exist because of cash flow. Notwithstanding projects performed on borrowed money, cash flow constrains all organizations in their ability to perform work during any specified time frame. No matter the ROI or the customer/client need, a project may be killed or not initiated simply because cash flow will not support it: End of story.
This is true on the client (delivery) side as well as the development side of the equation. Cash flow constrains all clients in what they can or can not purchase at any given time or withing any specific time frame. Ditto for providers, vendors, development.
William W. (Woody) Williams
Project Management Consultant
| Blog | Twitter |
w3src Consulting
True, it is reasonable to expect budget and time constraints on projects. When the money or time run out and the project is closed, the ROI is no longer relevant. However, [going over] time line and budget are sufficient criteria only for failure.
There has to be a different criteria for success.
Jane Prusakova
Software Architect & Developer
My blog
Totally agree.
William W. (Woody) Williams
Project Management Consultant
| Blog | Twitter |
w3src Consulting
Woody,
I agree that cash-flow is important to a project, no work can be done without it.
What I was saying is that, if a quality product is desired, someone has got to be the project's advocate. In other words, if the project is desired to make real and meaningful contributions to the future success of the client, someone has got to be empowered to make tough decisions on the project's behalf: i.e. asking for funds to be diverted to support it.
Of course I realize that the previous statement depends on the client initiating the project as a means to do better business rather than merely as an appearance of "doing something". Unfortunately, many people have made an artform out of looking busy while doing absolutely nothing (again, something is wrong with much of corporate america). This is partly because doing something is "risky".
I've seen a lot of software that has had all the "meat" chopped out of it to meet deadlines or budget constraints.
I don't know that I've seen a project where responsibility for decision making authority over budget was delegated to the person acting as the "customer".
I think a lot of potentially good projects wind up as failed endeavors because of a "weak" customer. Whether this is due to a lack of forward thinking and getting to know the customer before commiting to a project on part of the development firm or whether this was due to a lack of corporate courage on the part of the client probably varies greatly on a case by case basis.
I know that some shops act irresponsibly when building a bit of software, but let's stop self-flagellating as hard as we have been. Some of the responsibility for failed projects lies with the client.
My argument is not that money is not important, but rather should the driving factor in whether a project lives or dies be what is in the client's pocket right now? In the case of an over-extended client, then probably yes. But why would you get into bed with someone who can't take care of their financial responsibilities?
I would caution development firms against engaging in projects that are supposed to save the client's business, because if the project fails, who is writing the check?
I think that if "clients" were better educated about what an ordeal producing quality software can be (as risk averse as many of them seem to be), fewer of them would initiate the process in the first place. This might be bad for us software developers, but it could represent a culling of the herd and ultimately be good for the rest of humanity.
No matter how hard we work, if the business we are supposed to be supporting doesn't value the project, it is destined to fail.
To me, the signing of a software development contract is a lot like two people getting married. If their isn't faith and trust on both sides, the relationship should never be entered into in the first place.
I don't know about you, but I'm kinda tired of living in a world full of junk. Admittedly, some of which I had a hand in producing, but not because I wanted to.
Important concept: Cost of Quality.
It is a project budget line item or items. If it's not, it should be.
Performance factors (for success / acceptance) are another. Should be feature by feature as well as overall factors.
Customer or client roles in the project are (or should be if they're not) a part of the contract. The contract isn't a one-way street. What the client must do is equally, if not more, important than what you do for the client.
Quality Assurance these days (as a result of Deming, TCG, Lean, Kaizan, Kanban, et al) is largely a matter of process controls. That, coupled with Quality Controls should be a part of every contractual agreement.
The approach is "trust but verify." This is post-ENRON, post Merrill-Lynch.
Nothing "just happens" although at some levels or from the point of view of some roles there may be zero visibility. If that's the case, there is another issue ;~)
William W. (Woody) Williams
Project Management Consultant
| Blog | Twitter |
w3src Consulting
Robert,
I understand your frustration. Culture of blame is very hard to deal with if you care about your craft more than the office politics.
At the end of the day, the client decides how much of a quality and ROI they want from a product. The only thing one can do is to try to educate the client, and work on building a sense of excitement over a job well-done - be it a software product, highly responsive and knowledgeable support service, or a cup of coffee with WiFi on the side.
Jane Prusakova
Software Architect & Developer
My blog
Jane,
Unfortunately, you are right. The client does ultimately "decide" about the level of quality of the product at the feature level.
I still think that the development agency should try to inform clients what trading on quality is going to mean in the long run. Whether the client listens to the development firm or not, is entirely up to the client.
Development agencies reputations hinges on the work they've done in the past. This reputation is, as we can see, directly tied to the coorporations the development firm has done business with in the past. I wonder how many development corporations realize this let alone their current clients.
My message here is simple, don't allow yourself to fall victim to a client who commits to a project half-heartedly.