The Era of Software Engineering is over. It has been proved a failure methodology and practice by the high failure rate of software projects in the last 20 years.
The FDD, XP and other Agile methodoloies, which we also call 'lightweight methodologies', are good tries in creating the Post Software Engineering Era. But they are still not the right solutions because they are making the same mistakes as of the Software Engineering. This mistake, in my own words, is that the software development has been managed and controlled by software professionals. For example, the setting of Chief Programmer in the team is a typical such mistake.
The real Post Software Engineering Era, in my terms, will be in reality when the software development is NOT managed and controlled by software professionals.
I will spend more time and words on this subject later.
Wow! a troll
Its a junk post. I suggest deleting it.
I should have know better
Phil,
You were right. :P
David
I should also never more!
David,
I'm starting to get the grasp of your simple but deep comments :)
Nuno Lopes
Interesting teaser!
Looking Forward to you next post! But please be far more explicit about your framework of reasoning then you were on this one, so I can understand what you are trying to state.
Nuno Lopes
Agile not lightweight
Actually, "we" don't call them lightweight methodologies. The founders came up with the term Agile specifically to avoid the use of the term lightweight.
Completely and utterly and without question WRONG
The problem with software development is the LACK of professionals.
In my experience many of those in positions in IT with serious decision making power still have little in the way of formal training in software development or software management. Nor have they had the opportunity to be do a serious apprentice under someone that has.
Many people running IT are graduates from other disciplines that have for one reason or another moved into IT. In other words amatuers.
My wife as a qualified lawyer was required to have both before she could practice law. The same applies for all other traditional professions.
Steve
More on the Post Software Engineering Methodology
I was expecting at least one comment which understands what I was trying to state. Unfortunately, I think I need more time to encounter a matured software professional to speak.
Calm down everybody! It is not the end of the world yet.
First, please allow me to state my background. It might be a little bit 'show off'.
I was graduated from the Computer Science Department with Bachelor of Computer Sciences (for 5 years study) and Master of Computer Sciences (for 3 years study). Then got my MBA. I have over 15 years working experience in all roles of software development, including programmer, team leader, technical project manager, project manager, software department manager, chief technology officer, chief professional service officer, COO, CEO, and so on.
I have been involved in the development and implementation of over 100 projects, and now over viewing the development of over 20 projects concurrently. Some of the projects I involved were seriously failed. Some of them were great success.
OK, Let's now come to the core part of my opinion.
The serious mistake of Software Engineering methodologies including SSADM, RAD and XP, FDD is that they put the Software Professionals on the core roles. It is not saying that the development of the software project does not need software professionals. But they should and should only take 'technology core team' roles instead of other more critical roles like business analysts, QA, and even the project manager.
Let's talk about FDD, I believe there are some valueable ideas there. But it will drive the projects into another dead land, even more serious trouble land. FDD has been trying to resolve the issue of 'continuously changing requirement'. But in the reality, nothing is not changing. This is the core reason that Software Engineering methodologies fail. The sequence of project development is Requirement Spec, Design, Construction, QA, Implementation, Deployment, Maintenance and so on. The starting point is Requirement Specificaiton. This is the core and key part of the project development failures. When the requirement keeps changing, who and how can avoid failure?
SSADM failed, RAD failed. Now FDD? That would be a joke if you say FDD can resolve the problem. Why, because we so called software professionals still insist that we are the core part of the project development, while actually we have no power to control the project even the starting point of the project development (the requirement)!
When we project managers (and software professionals) declare that we are managing projects, we are not. We are doing what our customers tell us to. When customers say 'change', we change. When they say 'no', we are dead meat.
OK, now you may say 'hold on, I have new methodologies like FDD and XP and UML' to avoid at least improve the problems'. Are we? Are we controlling anything? Are we managing anything? The answer is NO. We are still following the commands of our customers. They are controlling and managing. We are not. We are following their instructions. We are their slave labours. Who would agree that a slave should be on key roles?
This is the core reason of the high failure rate of software projects (check the figures at CHAOS report site). In the last 20 years, the failure rate of software projects have been around 80%, if not higher. We software professionals are failures in general.
Agree?
So, the question is, how can we change such frustrating situation?
My answer is, put the software professionals on the right position. They should not control the development of projects. They should not even manage projects. What they can do? They can only be on two roles: design of pure technical stuff like the database schemes, and coding. Unfortunately, these two roles are almost least important ones in project development.
Who can be on key roles in the development of projects? That is our next topic to discuss. I will spend more words on that in the future.
Thanks every one. Again, please calm down.
Jonathan
But in the reality, nothing is not changing...
Did you mean that in your world the sky is pink and something is in fact changing?
Not sure of your question, but ...
I believe this is a common assumption in software industry that customer requirement is always changing. Look at FDD, you may find that it is the key assumption it has. The changing requirement is actually the fatal problem for software industry. FDD tries to resolve the problem in another approach. I believe it is still a failed try because it does not resolve the problem from the root. It only adds some new thoughts into the existing failed unhealthy pyramid.
We so called software professionals have no power to control the changing requirement. When we have no power to control the starting point, how can we say we can manage and control the whole process of the project?
We have been promoting software engineering methodologies (by the way, I see no major difference between FDD and other software engineering methodologies like SSADM). We compare software industry to the construction industry, which is proven absolutely wrong. In construction industry, the engineers do not need to deal with the ever changing requirement. When the architect and designers complete their work, they can withdraw from the construction project, whilst we software professionals cannot.
So, if we insist to compare the software industry with the construction industry, I can only say that the software industry is still on its baby era, just like when farmers build their houses without any design. They just build, build and build. They also deal with changing requirement and changing design. That happened in construction industry thousands years ago.
Jonathan
More about the customer requirement which keeps changing
I might have not stated my point clearly about the customer requirement. Yes, it is a fact and actually no need to assume that customer requirement keeps changing, from the begin to the end of the project development.
My point is, all methodologies under the umbrella of Software Engineering, including SSADM, RAD, now XP and FDD, have failed to deal with the changing requirement. The reason is that the software professionals have been placed on the key roles in the project development.
It is the root reason for the high failure rate of software projects.
The conclusion is that we need a new methodology which can resolve the root issue.
I call the new methodoloy the 'Post Software Engineering Methodology'.
Jonathan
OMG!
I for one welcome our new 'Post Software Engineering Methodology' overlords.
SSADM DSDM
so is there a great difference between ssadm and dsdm. Many say they are close to each other then any other methodology. Mnay have also recommended ssadm as the champion of methodologies, Is this true.
Lost for words
I won't honor this with comment other than...
Jeff, please do not delete this. It was the most amusement I have had on this site for months.
And on a serious note...
When we get an objective definition of "what management is" then we can have a discussion about whether FDD manages things correctly and whether the roles in FDD are appropriate or not.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Dadaism
David
I thought my dadaist/ism post was much funnier. Obviously no Tom Stoppard fans around!
phil
Still waiting for more info!!
I believe that what Jonathan is saying sounds interesting. It looks like a change in paradigm (paradigm shift?), so it is quite natural that most people can't really see it, or simply don't want to listen. I can't really fully see it without more info, but I must admit that his introductory concept rings a bell (at least for me).
Anyway still waiting for more info from Jonathan as just stating other ones "failures" (failed SDM paradigms?) in contrast with a paradigm that has never been put into to pratice or formalised (so of course never failed) is at least not a very good way to start a serious debate (specially when interveient are demanding professionals). Most of the times it is easier to diagnose what is failing then to implement the solution for it.
One thing interesting about FDD is the reporting features that the method provides. These reporting features are the core artifacts allowing non IT driven people (say a lawyer) to stear the project or diagnose problems. Yes a Lawyer could decide, turn left or right here, but could he actually push the wheel left or write in the most effective manner? I have some doupts. The most prolific CEO's and their rock solid companies that I've read about where actually from the companies field of expertise (Bill Gates, Ford, etc etc). So as for the moment without further information, to say that a CP should not be an IT person it is nonsense, or at least I'm not seeing through what Jonathan is stating (Why not a CP?).
So ... Jonathan wrote:
"Who can be on key roles in the development of projects? That is our next topic to discuss. I will spend more words on that in the future."
Still waiting for those words.
Nuno Lopes
PS: I too have a theory why most projects fail. Lack of Vision, quick fix attitudes, run away champions, too many unprepared meetings, unhealthy communication, lack of internal strategic value even though there might be an external one (so champion lost interest, leaves company or is promoted), lack of proactive behaviour from IT, user see that they jobs are at stake when the system is deployed, unhealthy sales process, naive PM's, lack of staff, missing dead lines, and so on and so on. Most of them are not related to a specific area of expertiese and or related to changing requirements (Requirements change, so what are you doing about it? Renaming or replacing roles, moving heads? What is the measurable impact of those changes?).
One more thing!
Generically I see a SDP as a meta data for the following formula:
Product = Requirements + Production + Production Capacity
Who takes care of Requirements and how is it taken care off within the scope of the company needs (Product)?
Who oversees Production? What are the artifacts that are used to analyse production.
Who takes care of Production Capacity?
Who bridges Production Capacity with Production (the + sign) - VERY IMPORTANT?
Who bridges the Requirements with Production Capacity and so on - VERY IMPORTANT?
Who oversees the Product?
Who oversses the formula? The all thing.
Probably if we start classifying SD problems in:
* Product
* Requirements
* Production
* Product Capacity
We could start understanding why most projects fail with no dogmas. I think that most problems are in the conjunctions.
Nuno Lopes
Just some help in visualizing the formula.
Think of each variable as water cups. If you put more or less water in Requirements, something will change in the Product cup. If you put more more or less water in the Product cup (yes you can do it), you have to distribute level water in either of the three cups on the right. One can stop/cancel the project any time. So in a failed project one has to ask what went wrong and when (keep track of formula value updates).
What happened with the Requirements, the Product, the Production (not enough output, missing deadlines) the Production Capacity (ill equiped team)? Are those conjunctions working correctly?
For instance if the Product champion is promoted or leaves and the project dies after 1 or 2 months (champion needs to be replaced), humm it means that the Product as changed. Where the correct cups updated to cope with this change and balance the formula once again?
Another example - In a team of two developers developing a critical feature, a dearest relative of one of the developers as passed away. So the PC is affected, was the PC variable, requierements, production (deadlines) or Products updated to balance once again the formula?
Let me tell you a small story that you probably already have heard. The Captain of a Battle Ship in a dark foggy night hails the nearest object in a collision course to move, "SS-NAVY-351, request unidentified craft to turn 35 degree south, at 35 knots or greater speed!". The answer to his hail was "Understand. Captain of SS-NAVY-352 move 45 degrees east, at 65 knots speed at least.". "I am the Captain of Battleship rank 35-3234, so according to law you need to move as I requested". "I'm a navy guard, third leutenant, move as I advised". "Move now or I'll take you to court martial for disregarding an order of a superior officer of a prority 1 Naval Ship" - said the captain. I fully understand the penalty but please do it after you move, I'm in the Lighthouse.
Nuno Lopes
My Point!
IMHO, a project can fail due to many reasons not concerned with a specific SDP. I believe that for most projects, technical problems are easily solved compared with other problems within the scope of management and correlated tasks. So to blame whatever SDP for the failure is not a good diagnoses of the problem, although an SDP that fits the bill is extremly important to achieve success.
As I understand Jonathan, he is arguing that the pressure of product delivery should be more balanced between up management and users, and developers. Within this I see that traditional SDP, including FDD somewhat relegate this issues to some meta process that is not described in deep.
For instance I see Domain Experts and Sponsor as the Keys to project success in FDD. Much more then the CP, Programmers or Modellers. Unfortunatly this Keys are often not consistently available, or are available in an disorganized time framework, or engagement on their part is little (quite often this is not their fault either).
If you look at a sales process of a project, most of the times in Portugal we go and tell the client what he needs, he/she likes it, and buys it. I think that this attitude is disfunctional with respect to project success, but I don't have a solution fits all for this. As "ridiculous" it may seem is what most clients want. The upper management of clients say: "look Nuno, I trust you to solve this as I don't think we are not prepared (the clients Domain Experts) to give you input on the required solution, we simply don't have the time, the skills, or are not organized to think about it at the level it is required.
Nuno Lopes
Who should manage IT projects?
I promised to discuss more about the Post Software Engineering Methodology. I am happy to see many of the discussions are getting there...
I would rather to drop certain points when questions are raised. If anybody interested, maybe we can work on the new book together :)
Here are two of the key points why an IT professional cannot be on the role of managing the project development. 1) 99% of the software projects are NOT for the software industry; 2) We software professionals do not know what we are developing. We are 'slave' workers who perform what we are told to.
To the industry of these projects, we so called 'software professional' are 100% of non professionals. We do not understand the business. We do not understand their language. We do not know their people relationship. To them, we are far away from 'professionals'!
In more 'software professional' terms, the software development is the process of interpreting languages. That is to say, we are at most the very skilled intepretors between communication parties. Who are the leaders/managers of the conversation? The intepretors?
Jonathan
Humm puzzled :)
Jonathan wrote:
"1) 99% of the software projects are NOT for the software industry;"
"2) We software professionals do not know what we are developing. We are 'slave' workers who perform what we are told to."
I believe this is not a good premise for change. If we look at other types "products" (cars, pills, cakes, whatever), they are built/developed/cooked, sold and marketed in 99% of cases to consumers that are not in the same field of the suppliers. The tricky part is to understand the consumers/users while not putting them in charge of development. Why? Becouse they don't want to manage the development of the products in 99% of the cases, neither they have the skills or the time to.
IMHO, if you want to succeed with a new SD Process in comparison with others industries you need to understand this reality (In fact that is what all SDP take as a normal premise). Simply stating the "Laywer" is in charge, does not solve the problem. In fact tha "Laywer" will probably delegate the task to some other coleague, or hire a consultant to do the job, even worst, he can his/her secretary to do the Job.
So for me your initial concern do ring a bell, but IMHO in practice your conclusion do not work, at least in my environment. So I was hoping and looking for another conclusion.
Nuno Lopes
A little bit side tracked ...
If you check my first writing, my point was that, 1) the Software Engineering methodologies including SSADM, RAD and now XP, FDD are proven failed methodologies. So we need more practical methodologies for us to manage and control the development of projects; 2) That the 'software professionals' have been on the key roles of project development is the major cause of such failures.
Re 1), all of the current software development methodologies have been developed by software professionals, which has been proven a failed practice. So, I would rather to work together with non software professional to work out the new methodologies.
Re 2), we software professionals should be placed onto the right positions in project development. Their roles are no more than a) designer of pure software stuff like database scheme; b) programmers. All other key roles like business analysis, system analysis, testing, QA manager, project coordinator, and even the project manager, should be taken by what we call 'non software professionals'.
Why is that? 1) in the last 20 years or so, software professionals have failed in software development (check the CHAOS report). We should now give other people (and other methodologies) the oppotunities; 2) we software professionals are doing our job in the way of what WE think is correct instead of whay the way it should be.
In my company last year, a team of software gurus developed a fantastic software, which allows user to do any kind of reporting and searching. By the way, it was writen on the 'Requirement Specification' that user wants to do any kind of searching and reporting. User approved that requirement. The team presented the powerful software package to the customer. In just one week, the customer top managers wrote a serious complaint letter to us saying that it is just a pile of rubish. It is too complex and needs too much of their time to perform a simple (to them) searching and reporting. The user's time has been spent on composing the searching criteria while that should not be the case. Their time and efforts should be allocated in their business, instead of using our software. What they want is very simple, click one button, a report is produced. To us the so called 'software professional', such a stupid reporting function is too easy and does not worth our effort.
In the above case, several roles made their serious mistakes, including the business analyst, business flow designer, QA manager and most of all, the project manager. These are what we call 'software professionals'! The 'fantastic work' in our views becomes a pile of rubish!
Check the products from Microsoft, they are basically piles of rubish. (Sorry to say this) Check your own work, you will find that most of them are piles of rubish too.
This is the huge gap between us the software professionals and our customers. It is the failure of the methodologies that we have been applying. It is also the failure of the software professionals.
Jonathan
I'm interested in your next Book!
It's seams like in the project of your company something went wrong. What SDP it was used? Was the SDP really well implemented?
You've said that only after the software was fisnished the customer cought all usability issues (failed on criteria 1, check bellow). It seams to me that the QA as not done his job right (what method was used for usability testing? Was this carried really out?), irrespective if you have sofware gurus in the team or not. For instance:
"By the way, it was writen on the 'Requirement Specification' that user wants to do any kind of searching and reporting"
Really? It seams that this was not the case as the software was classified as "rubish". The point is, that any software guru should know that reporting can be really simple or very complex. Take for example the reporting tools that exist on the market (Crystal Reports). Irrespective of UI (simple, wizards, or whatever) for really complex reports I believe that one needs someone with advanced knowledge of the reporting system. Any Information Architect would probably help on this issues (check http://www.info-arch.org/lists/sigia-l/).
I'm a former product manager of a DM/CMS Company company specialized in the Pharmaceutical Industry. One of the things that I implemented in the company was Usability Testing! It was a huge jump in usability/quality once it was implemented, and customer were far more pleased. But we are talking about a commercial product here.
You blame the process for the failures. You might be right, but I for one think that is a question of "maturity" of the all SD/Production line in most projects. A good PM understands how the production line works, the different artifacts involved, how they can be used, and what is their impact in the ned product. I don't know if a "Lawyer" with no understanding of software developement would be better equiped to assess this.
The conclusions of the CHAOS Report are here:
http://www.standishgroup.com/sample_research/PDFpages/chaos1999.pdf
http://www.pm2go.com/sample_research/chaos_1994_4.php
Notice what is pointed as the number one measure for success:
Success Criteria Points
1. User Involvement
2. Executive Management Support
3. Clear Statement of Requirements
4. Proper Planning
5. Realistic Expectations
6. Smaller Project Milestones
7. Competent Staff
8. Ownership
9. Clear Vision & Objectives
10. Hard-Working, Focused Staff
What most SDP books lack is a lot of meta-data around the process concerning the different/multiple facets of software development. For instance FDD focuses on the Problem Domain, and it defines the problem domain as the business process that will be mapped to the PD Layer. It lacks a consistent approach for the UI Develoment Process (UI Requirements, Usability etc etc) for instance. But for the PD is maked IMHO a awsome Job.
I've for one never seen a SDP that tackles all nuances of the formula that I've posted (tackles the the issue of changing requirements in a relational manner). I was hoping someone could eventually post some comments on that, including you. The methodology followed by the Standish Group to analyse project failures is IMHO different.
As for your two last remarks, I believe that you are psychologically striving to start designing SDP from a clean sheet and justifying the its need with two words "everything is rubish, starting from people/gurus". I for one think that this is not a responsible way to start. If you want to start with a clean sheet, dot it but probably in a more constructive manner.
"It is also the failure of the software professionals."
I agree, so we must solve this failures and not simply stating that we are uncapable of doing better. CHAOS Report concludes with overwhelming figures, but I'm everyday overwhelmed about the fact that in 20 years, software is everywhere to the point that companies can't operate without it, so something was done right, but probably not in the most efficient manner. The most prolific companies are in IT.
I for one believe that any professional that is developing software should know this report, unfortunatly most don't.
Concluding, I'm interested in your book as it may turn to be quite interesting. But any good author knows how to listen too.
Nuno Lopes
I would suggest!
I would suggest applying the CHAOS Report analysis methodology to your failing project. Probably you would be suprised with the outcome. I have done that with one of my own.
Probably a questionaire to your customer concerning how they evaluate each criteria in the report.
Once done that, probably you and your team will know what really failed. Let's say you will know what is inside the "rubish" :) So next time who ever is concerned will be more then prepared and confident about results (knowing how to customize a process)
Nuno Lopes
Seems like your suggesting th
Seems like your suggesting that developers lack of domain knowledge is a core problem. True that often we don't understand the business case, in fact I often hear managers who haven't a clue about software cite this as the problem. You could say that the opposite is also true: the Business People do not understand software development. They do not understand the the language of development, or the people relationships involved.
As a developer working in the same domain for several years, I know the domain backwards. I can even occasionally point out problems that the domain experts (this is their life career, don't forget) have missed. Yet still projects struggle through these domain experts complete lack of software knowledge, allied with their desire to totally control this process they don't understand.
So no, the problem is rarely 'software professionals' in control. It's that control is being held by complete software un-professionals. Have you read "Peopleware" by DeMarco & Lister? Most of what's wrong with development is in there and was known nearly 20 years ago. Sadly, most managers have not changed, though.
BTW IS it just me who doubts the integrity of the thread instigator?
Take a look at http://thingy.apana.org.au/~fun/fuckhead.html and see how many f***head symptoms are being displayed here....
Irony
Is it just me that finds it ironic that an anonymous user questions the integrity of another user
It is not just about understanding the business
Based on some of the comments, it seems to them that the problems in software industry are caused by the lack of domain knowledge. So, one may suggest to have more domain experts like business consultants in the development team.
The problem is not that simple. Yes, we should have domain experts. But these domain experts are 'pure' domain experts. They should NOT have IT knowledge. That is to say, they are standard non-software professionals.
Another point Nuno and some other guys suggested is to enhance the 'testing' especially the usability tests. In traditional development methodologies, testing is after the construction phase. In FDD, it is before. No matter where it is, it resolves SOME of the development issues. It cannot resolve the problem from the root. In the way I am talking about (the Post Software Engineering Methodology), these QA people should have no knowledge of software at all, i.e. they are non software professionals. Of course, I am not talking about the unit tests.
OK, how many key roles should not be taken by software professionals? Two at least, right?
(I guess we need to define the term 'software professional'. We have not do that yet? Hope we are talking about the same group of people i.e. people who have educational background and working experiences in software technology domain. Still arguable?)
You may argue 'how about the project manager'. Well, I am not insisting this role must be taken by non software professionals. But I would rather they are semi software professionals, for example management background with certain IT experties. I would never put a 'real' software professional onto the project manager's role. An effective project manager would not spend more than 1/5 of his time on software domain.
So, we have already identified 2.8 of the key roles should be taken by non software professionals. What roles still left in a project? 1) Pure technology designers like database scheme designer; 2) programmer. This is exactly what I have been trying to state: put the software professionals onto the right roles in the project. These roles (less than 2.2) are NOT the key ones. The software project should be handled in a way of non software professional. That is what I have been talking about.
Regarding the sample I presented in my previous post, I forgot to tell you Nuno that user was involved in the development. The softare package was thoroughly tested by the representatives from user's site. These people were from the IT department i.e. people under CIO. There were also people from business departments, from time to time. It is 100% normal right? These people also agreed that our system was a piece of 'fantastic work'.
But the end user of the system was the top managers of the enterprise i.e. COO and CEOs who you can never expect to be involved in the lengthy QA or testing phases. We are talking about the reality, not in theory. In theory, we can write a letter to the top management telling them that 'sorry, you are wrong. Your people have tested the system and approved'. Can you do that? Of course you can, only if you do not want to have more contracts from them.
I believe we have to say 'no' to ourselves before we software professionals can really do something right.
Jonathan
Not arguing for the sake of argumentation but ...
"But the end user of the system was the top managers of the enterprise i.e. COO and CEOs who you can never expect to be involved in the lengthy QA or testing phases."
The point is that test subjects (the people that would use the software) never saw it before it was finished so it is not surprising that the output was "rubish".
"These people were from the IT department i.e. people under CIO. There were also people from business departments, from time to time. It is 100% normal right?"
No, the people that will use the software should be present in the QA phase otherwise how can you garantee satisfaction? Take the TableT PC for example, Microsoft offered Tablet PC for free to CEO's and otherr top executives, the people that were supposed to be the initial primary targets.
"But the end user of the system was the top managers of the enterprise i.e. COO and CEOs who you can never expect to be involved in the lengthy QA or testing phases."
Furthermore the primary Domain Experts were never involved in the development process. So basically ...
"QA people should have no knowledge of software at all"
QA/Usability testing subjects usually don't have knowldege of software development, neither they are experts in software tools. One of the primary initial excersises of defining a usability testing system is defining the so called Personas. This Personas decribe the target audience of the software (User Profile). So what I can deduce from your description is that QA testing was not performed by a experienced professional or someone with knowldge about it.
You say:
"The software package was thoroughly tested by the representatives from user's site. These people were from the IT department i.e. people under CIO."
And you think that this process is in pratice done as required, probably in theory, but in practice no! But then...
"But the end user of the system was the top managers of the enterprise i.e. COO and CEOs"
So bottom line is, wether your team managed to get them (the CEO, COO) on the board or someone really close to them (knows them, understands them, works with them day in day out) or you tests will be fundamentally flawed.
So according to your description who should be in that specific project leading QA? Someone with an MBA and a PHD in Finance? Possibly you may be right, but I fail to see how. A person fitting this profile should most probably be an excellent test subject (was someone that fit this profile involved in testing? I think not!), but I fail why this person would better equiped to manage QA/Usability the someone with large experience and with a some PHD in Human / Machine Interfaces.
Just some food for thought!
"We are talking about the reality, not in theory. In theory, we can write a letter to the top management telling them that 'sorry, you are wrong."
Where they ever asked to be involved? Probably not formal involvement, but was the system installed in they "laptops" for them to "play" with?
"Your people have tested the system and approved'. Can you do that?"
Sorry, the people who approved the system did not have the authority to (although It may have seamed during SD that they had). So of course you could not say that!
Honestly your description rings a bell to me, but I believe your conclusion is a wee bit of a jump in to the vacuum. Can you tell me for sure that if a person fitting the profile (Finance MBA etc etc) described above would convinve the CEO to be involved in the testing phase? Do you know? So what is the point of putting them in charge of QA? They could be for instance important test subjects?
"1) Pure technology designers like database scheme designer; 2) programmer."
If you read the book about FDD you will see far more possible technical roles.
"These people also agreed that our system was a piece of 'fantastic work'."
Was it tested for "bugs" (malfunctioning) or usability? I reiterate, your test subjects where not representives of the user population. Sorry to tell you, but testing environment you decribed is a Joke. It was built to give people a sense that the system was working as required, and the team only figured that out when it was too late!
"The problem is not that simple. Yes, we should have domain experts. But these domain experts are 'pure' domain experts. They should NOT have IT knowledge"
Absolutely, if the population is not IT!!!
"In the way I am talking about (the Post Software Engineering Methodology), these QA people should have no knowledge of software at all, i.e. they are non software professionals."
I would not say QA people, but usability subjects fitting the profile of the target population. So you figured that out by your self? The consequences you already described. The solution is in understanding why it happened (probably someone thought of a silly shortcut to avoid CEO's envolvement), and from now on do it right from the start.
So essentially:
1. User Involvement (by your description did not happened!)
2. Executive Management Support (was not fully focused on what was necessary to garantee success)
5. Realistic Expectations (probably yes probably not, but I bet the problem was in the interpretation of the requirement you described)
6. Smaller Project Milestones (how many preliminary releases to users?)
Notice, for criteria 1) the value is 0000000 or close to it!
Nuno Lopes
You might be right, but in the theory of software engineering...
I think Nuno you are still talking in the language of Software Engineering Methodologies, and basically you are still staying on the level of theory. Do you have the experience when the CEOs fall into sleep while you are presenting your Requirement Specification and/or Screen Designs to them? If you do, have you ever think about why? If not, I guess you need more real project experiences.
The reason I emphased that the key roles in software project development should not be taken by Software Professionals is that, software professionals have totally different thinking philosophies compared to the people in the real world. We think we have been right in the last 20 years. But the outside people do not think in the same way as we do. Due to historical reasons, the software professionals have the same thinking philosophy as of mathematicians who simplifies the real problems and solve the problems in a simplified and abstracted environment/conditions. Look at the software methodologies we have created and practiced for software development including SSADM, RAD, XP and FDD, we software professionals have been just another group of mathematicians who are solving the outside world problems in OUR way instead of THE way.
In the end after these 20 years, we suddenly found that we cannot simplify the conditions and environment to provide solutions to the real world. We cannot do things and think like mathematicians any more. (Well, some of us can. These people are the software professionals.) We have to break up the simplification process and barriers, go back to the real world to think and do our work in the way of the real world.
By the way, all steps you mentioned in your post was followed by the team, because the team believed in Software Engineering Methodologies. User representatives got their authorities too, in written.
It seems that few of us are discussing this topic. If that is the case, I guess I should rather focus on finalizing my work. But anyway thanks Jeff, Nuno and everybody for your help and comments.
Jonathan
Transferal People are Very Valuable
Jonathan,
If you are arguing that it is important to have people who can understand the software world and in turn understand business and adequately translate between the two, then I doubt whether you will get much argument about that from the members of this site.
You seem to be arguing further that software development won't get really "real" until the tools allow people who understand business to build their own tools without a translation into some arcane language such as Java. Again, I don't think that you'd get much argument about that here from the members.
However, where you will get an argument is in the practicality of you prognostication. We live in a world of today's tools. And in today's world, we still build software in fairly 3rd generation languages and associated libraries and development tools. Logical flow of information is controled by programmers writing programs in some code. Hence, in order to build business systems in today's world, we still need these technical people and we still need them to be managed in an efficient form.
Do we need people who can bridge-the-gap? Yes, we do!
Are those people highly valued? Yes, they are!
Would it be good if those people could just press a few buttons and working software popped out? Yes, it would!
Or better yet, allow business people to build their own tools? Yes, it would!
Is that paradigm shift coming? Yes, I believe it is!
Is it coming in a timeframe that I need be worried about completing my car payments before I lose my job? No, it isn't. Not for this model car, or my next one or the next one after that.
In the meantime, we in the FDD commmunity continue to live in the real world.
At this point, I fully expect you to reveal yourself as someone with a semantic network development tool to sell (or some other fanciful 4th or 5th generation tool). If you think you have the paradigm shifting solution - then go make it happen. Meanwhile in FDD land, we'll keep over-delivering on promises by bringing in large projects, on-time, on-budget with client-satisfaction in the functionality delivered.
Thanks.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
The software professionals still have their roles in project...
David,
I might have been too emphasizing the function and importance of non software professionals in project development. Actually, those software professionals (what I mean was those sort of mathematicians) still have roles to play in project development, for example the designers of the pure software stuff like database scheme and programmer. My argument point is that, other key roles should not be taken by software professionals.
Let's take the business analyst role for example. This key role should be taken by 100% non software professional in my methodology. They know everything about the business but do not know anything about software development like database scheme, Java, and so on. Knowledge and skills of software are burden to certain type of jobs. They should be 100% from the industrial fields like Car Manufacturing. Even the designer of the system (I mean the designer for function, data flow, functional flow, work flow and so on, not the technological designs) should also be sort of 100% non software professionals.
Having said that, I am not denying the functions of the software professional. They still have their roles to play. At the moment and following the methodologies we have in hands, they occupy too much space. They should let out certain space to non software professionals.
Actually tell you what, in one of my success projects that involved over 4000 man/days, the Requirement Spec and Logical Design part were allocated to the teams whose members are of 95% directly contracted from our client. Only the team leader was hired by the company. Again, this team leader's knowledge in computer was limited to MS Office.
I am not saying all projects should be following my methodology. But I have tasted the great success of my practice (I named it the Post Software Engineering Methodology). You may imagine that when noisy voices raised from customers, how the Requirement Teams and Logical Design Teams were defending the project - because that was THEIR work.
Yes, I do aware that my methodology brings negative impacts to us the software professionals. What we are discussing is how to make projects successful, not how to keep every software professional a job. Besides, I am getting more and more understand why there is no award for mathematicians in Nobel...
Jonathan
Interesting!
Hi,
"Actually tell you what, in one of my success projects that involved over 4000 man/days, the Requirement Spec and Logical Design part were allocated to the teams whose members are of 95% directly contracted from our client."
This is very interesting indeed. This is the optimum case - extreme collaboration and leadership expertiese from the client. I love it!!
The projects that I have been involded, this kind of client involvement was next to impossible, but if it is possible then for sure I would support this idea.
Most of my clients hire external services to do this kind of job, becouse they don't have the time, don't thrust they own executives to lead it (political concerns, sponsor), and they don't have spare personnel to engage into leading the project in such manner.
Some clients prefer to hire people from a top consultant company to do the requirements and analysis, and some other company to do the programming. I have seen projects where analysis and requirements where done by people that where not from IT (Background in finance, management etc). SAP solutions commonly use this paradigm (Andersen, PWC etc). I believe that some of the failures mentioned by CHAOS are within this scope.
So putting non IT people in Requirements and Analysis did not garantee success (the pay by word Syndrom). Put stakeholders to make the analysys and requirements by themselfs sounds interesting though, but my clients hire external services just to avoid this.
I'm looking at it from the point of view of assembling such a team.
How would you suggest such a team to be assembled in an environment where companies/clients are basically making people redundant? Also would you suggest doing it when the culture is - "If you want to get the job done, don't give the job to your own people"
Nuno Lopes
So why are you interested in FDD ?
Jonathan
,
I am trying to keep an open mind on your comments, trying to understand your approach or alternative. I would encourage you to post some details about this method/process/framework/organisation. What is it that you are suggsting should be adopted ?
Let's take the business analyst role for example. This key role should be taken by 100% non software professional in my methodology. They know everything about the business but do not know anything about software development.
If the BAs are from the client and are solely expects in the business then where does any innovation come from in building requirements ? Understanding what the business does today may not be enough.
Even the designer of the system (I mean the designer for function, data flow, functional flow, work flow and so on, not the technological designs) should also be sort of 100% non software professionals.
What are the skills you believe are critical or desirable to fill this role ?
Actually tell you what, in one of my success projects that involved over 4000 man/days, the Requirement Spec and Logical Design part were allocated to the teams whose members are of 95% directly contracted from our client. I presume this is not the same company where the CEO wrote the letter of complaint :).
It sounds like a medium sized project, could you provide some more information of how it was staffed and the staffing profile,
I am not saying all projects should be following my methodology.
In looking at a project about to start what attributes would you be looking for to determine the fit to your "methodology". Until you have some artifacts to share I doubt you can really call it a methodology.
Finally I am curious in why you are interested in FDD. It just seems you have your own "methodology", you are confident it is a better than FDD.
David
I like some of the ideas in FDD
David,
When I was talking about the Business Analyst, I did not say that the BA should just on the level of 'understanding the business'. They are FROM the business domains, not us software professionals. The project I mentioned (4000 man/days), the Requirement Team leader I hired had 15 years working experiences in Logistics; all team members contracted from our client were experienced logistics operators and/or managers. When you say 'let the team members to understand the business', you are still speaking in the term of Software Engineering. I am trying not to go in that way anymore. Actually, in the project, many of the team members did not understand the business at all, and I deliberately let them not to. (I admit that there are certain political factors here. ) This is also anti the principles of Software Engineering Methodologies, right?
All methodologies so far are scared of Requirement Changes. The Agile Methodologies including XP/FDD claim they welcome changes. How? By shorten the iterative cycle. That is still to 'react' to the scary thing - requirement changes. Remember someone in this group recommended me to read the book '7 Habits'. The first habit in the book was to 'proactive' instead of 'reactive'. To shorten the iterative cycle is still reactive, but just maybe more effectively. That is why I say FDD has just added certain good ideas to the existing unhealthy pyramid. It does not resolve the problem from the root. They are still scared of the requirement changes.
Why I am here in the FDD group? I think I already said that there are certain new ideas there which I like, for example the way of testing. Actually, to test the project (not the system) from the start of the project is the practice I have been using in the last five years. On business analysis (Requirement Spec) phase, the Requirement Team already prepared the first draft of their 'Test Plans' which are entailed, adjusted and tested against in other phases like Design, Construction & Unit Test, Integration Test, Acceptance Test and so on.
I would not say that FDD is a new methodology either unless we have a common definition in the term 'methodology'. Actually, FDD is just some working rules + Software Engineering Methodology. Whether something is something is not measured by whether the creator has written one or too books.
Re the Innovative Ideas you mentioned. I am not sure what you mean by 'innovative ideas'. You mean requirements that our client does not want and we think they want? That is another 'dead land' I have been trying to escape from. For too long time, we software professionals have been playing the role of the 'God' who says 'I tell you what you want' whilst we deliver what our clients do not want. I do not want to play the God any more.
If you mean technological innovation, that is the work of us software professionals to do. I would not worry on that since we have too many that kind of professionals already.
Jonathan
To clarify the statement
Just to clarify the statement in my previous post that,
'Actually, in the project, many of the team members did not understand the business at all, and I deliberately let them not to.'
Here, by 'many of the team members' I mean many of the project members and most of them being software professionals. Of course they are not the members from Requirement Team, Design Team, QA team, PM and some other roles.
Again, it is anti Software Engineering Methodologies.
Interative cycle at al.
Jonathan,
"All methodologies so far are scared of Requirement Changes. The Agile Methodologies including XP/FDD claim they welcome changes. How? By shorten the iterative cycle. That is still to 'react' to the scary thing - requirement changes. Remember someone in this group recommended me to read the book '7 Habits'."
Can you explain better this part? For instance, I understand that a very good team (15 years of experience in the problem domain and fully dedicated to the project, very nice) from the business domain facilitates a lot of things when analysis and requirements are concerned, for instance analysis paralesisis can be greately avoided etc. I can even see this to the point that number of requirement changes tend to be lower.
What I don't understand is why short interactions are reactive rather then proactive when it comes to changes in requirements. Short iteration cycles, as far as I ever perceived tackles the problem of validation. That is, if more often the software is validated against requirements and users the better as it spurs communication. Being able to absorve changes, for me is more of a side effect (most changes in requirements are not really changes as far as the clients is concerned, but lack of understanding)
In other words, within the scope of your thinking (methodology) how do you tackle the problem of validation? What is the importance of schedule incremental deliveries, to facilitate testing and validation, how long is enough time for a cycle, etc? It seams that you don't need this anymore.
Would you concider a full requirements phase, then analysys, then full implementation. Or several interative cycles?
What about prototypes? How do they fit in your methodology. After all if a domain expert is leading requirements and analysis, probably a prototype is not needed anymore, as "we" now "own" through the "domain expert" the knowledge required for an excellent preception about the needs and what they involve.
One Key element of all processes as I understand is the seldom availability of the so called domain experts, wether they are team leaders or not (a Domain Expert is a Key Role as I see it). If domain experts are available full time, that is excellent. This is what most software professionals want! If it is necessary to put them leading some stages such as requirements, analysys, in order to get their attention, and they are equiped to do it, is a minor detail. But once involved in such manner they Job do not end when some requirements, analysis doc is delivered, they need to interact with CP's during the course of the project in order to assure the software professional are interpreting the analysys and requirements documentation correctly. So at some point the interpretation of the requirements and analysis in to the software system needs to be validated.
As far as I understand FDD tries to free domain experts a much as it is possible, becouse it is what usually is required by the environment (not always, but most often the not). Furthermore, it puts emphasis in short iterative cycles in order to enforce validation while keeping their need in balance with their availability.
Probably around FDD, a book about the importance of Domain Experts is what is required, as I can fully see that it can be perceived of little importance compared to other project members when we read the book (more speal is dedicated to the importance of CP, Programmers et al then the Domain Experts).
Proactive or reactive
Hi,
I think we are getting to the core of what I have been trying to state in the last number of posts. You have raised several key questions about the new method.
Before talking about my answer to your questions, I would like to express my worry on the idea of 'shorten iterative development cycle', from which you may understand why I still believe it is reactive to the problem instead of proactive to it.
The beauty of Software Engineering is its overall design and overall picture. The theory and practice was borrowed from the traditional industrial domains like construction engineering, in which 20% of the effort is allocated to design and 80% is allocated to construction. In those methodologies, it is assumed that as long as the design is right, the project is almost (say 80%) to be completed on budget, on time and on customer needs.
There are huge differences between construction engineering and software development in which 80% effort should be allocated to non-construction part. Even you have got a perfect design, the project may still go wrong. Right? I don't want to go further in this direction.
Come back to the software engineering methodology. Its beauty is the 'predictability' (at least expected so). Now we found we have a major problem being that we are reacting to the core problem - customer requirements.
By shorten the iterative development cycle is still in the philosophy of 'break it and conquer it'. The huge risk here is that we are losing the last bit of beauty of software engineering the predictability and overall control of the project. We would be driven into the 'long and discrete noodle' situation where we quickly lose the whole picture of the project. We may start with the destination of New York but end up with Hong Kong or nowhere. We may get every single tree but lose the whole forest. Unfortunately in software development, 1+1+1+1... does not equal to the whole.
Jonathan
Please answer my questions.
Hi Jonathan,
Please answer my previous question Jonathan. Anyway here are some more.
You wrote:
"The theory and practice was borrowed from the traditional industrial domains like construction engineering, in which 20% of the effort is allocated to design and 80% is allocated to construction."
"There are huge differences between construction engineering and software development in which 80% effort should be allocated to non-construction part."
So you argue that 80% of the effort should be put on the requirements, analysis and design. Furthermore you are stating that almost all analysis and design should be made up front. This basically the waterfall SD method with one interation which basically has failed (akcknowldged as a bad, naive model). Now as far as I inderstand you argue that this method as failed becouse the Business People were not key to its success, this is far from the truth as far I know. Having worked with Andersen and PWC and others, what I've seen is that this companies seldom apply their business consultants (experts in business, managment), sometimes they even have specialized consultants in veritical markets (Automotive, Pharma, Retail, Banking, Insurance, etc etc) and still this model have failed (of course some projects have suceeded but their are not the rule. It takes longer to finish the project, requires more people and usually budgets go sky rocket.
"Come back to the software engineering methodology. Its beauty is the 'predictability' (at least expected so). Now we found we have a major problem being that we are reacting to the core problem - customer requirements."
I don't think that we are reacting when we think we need smaller iterations but tackling the main issue of validation. Anyway at most we are reacting to a failed model.
Anyway, so as far as I understand all your posts, your solution, is for us to go back to the waterfall model with Business People in charge of Requierements, Analysis, and design? I believe that this as already been tried and aknowledged has not a good method in most cases. In fact, if it was such as success we would not be here discussing methodologies. But I may be wrong, please clarify.
Nuno Lopes
Validation!
Hi,
I used the term of validation as it is used in maths. In this case the ouput of a function needs to match an expected result in a specific paradigm, world or model. In our case the software is the function, so the only way to fully validate its to run the software in a environment _very_close_ to its natural, and still most the times the problem is what we mean by _very_close_. And even if the correct balance is found, it does not mean that it will behave as expected once deployed, no matter the ammount of requirements, analysis and design you do (it may seam that is all correct (users validated the requierements, design and analisis). This is precisely one of the important insights that these new SD methods capture.
I honestly don't believe anymore in any SD method that does take this into account, in other words an SD method that is built on the premiss - ValidX(B(Design, B(Analisis, B(Requirements))) => ValidY(B(Software)) Else Raise("ValidY screwed up").
Nuno Lopes
Promotion of FDD and my understanding of software validation
Nuno,
Sorry that I have been away from this site since the heavy work load in the last couple of weeks. Tell you what, I have called a two days seminar in the company with over 30 senior development managers to discuss the latest development of methodologies, including XP and FDD. We presented FDD in a way of more positive than my personal attitude. In China, not many people know FDD yet. We had a hot discussion. Hope Jeff or other FDD gurus have opportunities to visit China and/or Hong Kong to promote FDD, on which I can be of some help.
Regarding the 'validation' concept you mentioned, my understanding is that we should view it not only from the angle of 'pure software', but also more from the angle of 'non software'. Software becomes nothing without considering its external factors and environment.
I see all of the testing design and implementation processes be part of the validation and verification process. We also have Independent Validation and Verification (IV&V) which see validation from the third person's angle. The IV&V party might have no knowledge of requirement, software and whatever. They just perform IV&V tasks from certain angles like Project Management Methodology and Project Development Methodology.
If we insist to work out a formula for the Validation, the factors that are not specified in 'Requirement' might also be part of the validation process.
One of my projects invited a legal firm as our IV&V party. They only concern the legal terms in our documents and communications amongst project stakeholders, while they really don't care about even what is the requirement or software stuff.
Jonathan
We agree on this one!
Hi Jonathan, thanks for your reply,
You wrote:
"Regarding the 'validation' concept you mentioned, my understanding is that we should view it not only from the angle of 'pure software', but also more from the angle of 'non software'."
Absolutely. When I wrote:
"In this case the ouput of a function needs to match an expected result in a specific paradigm, world or model."
The world is not necessarly a software environment, which is a very dull and "simplistic" environment, but also a business environment or any other environment that the system will be deployed on.
What I think is that small DBF iterations facilitate this. I agree with you that the literature around FDD is more inclined to software by software testing (unit tests, code review et al). But I think the model is pluggable enough to encompass a broader development environment that includes validation in the broader sense that I'm talking about.
"If we insist to work out a formula for the Validation, the factors that are not specified in 'Requirement' might also be part of the validation process."
Again I believe the small iterations of FDD facilitate this really well, prior to testing. If you notice there is a design phase (which I think is a two phase design) in the DBF where the Domain Expert needs to be envolved to workout details, giving the team another opportunity to spot "things" that were not captured during requirements or analisis phase. This is a very interactive development process. Even during DBF phase I believe the Domain Expert is KEY to its success given such opportunity.
Nuno Lopes
One little detail!
I'm not sure if I understood this,
"One of my projects invited a legal firm as our IV&V party. They only concern the legal terms in our documents and communications amongst project stakeholders, while they really don't care about even what is the requirement or software stuff."
Well, as far as I understand, this can be a component of the validation but is one such that does not inherently contribute to the validation goal. In order words is more of a strange attractor that is put to use due some organization policy concerning Project Management / Outsourcing. As any strange attractor (strange in the sense it does not contribute to the specific goal of validation - a successfull working software system) we need to be carefull with it as it may deviate us from the main goal of the project,
Nuno Lopes
I still dont get it
Jonathan,
I am sorry I still dont get what you are proposing as an answer.
When I was talking about the Business Analyst, I did not say that the BA should just on the level of 'understanding the business'. They are FROM the business domains, not us software professionals.
This is because you believe Business Analysts should be experts in the business. In my experience the problem you can run into with this approach:
When I use the term innovation I mean it in the sense of exploring with the business new business processes. I am not looking at this from a software professional background but bringing in real business thought leaders. This is where a lot of consulting companies sell their âadded valueâ to clients. They are not using software professionals, but a range of people from varied background who can run workshops around business assessment, business strategy and vision.
I could see your approach working on a project that was not strategic to the business, i.e. this part of the business is a cost in the business that we are looking for technology to reduce. Please look at my previous post and take a short time to answer some of the questions (e.g. What attributes of a project are you looking at to make a determination of fit of your approach ?)
Actually, in the project, many of the team members did not understand the business at all, and I deliberately let them not to. (I admit that there are certain political factors here. ) This is also anti the principles of Software Engineering Methodologies, right?
Which principle of Software Engineering Methodology are you referring to above ? The projects I work on, which tend to be larger than what youâve described, most of the software people in those projects would have limited knowledge of the business.
All methodologies so far are scared of Requirement Changes.
. I donât think âscaredâ is an accurate description, since all the methodologies I have used include a process of managing change (all types of change not just requirements).
I do not want to play the God any more.
Thank goodness for that as I kept having to go around clearing up my name :)
David
P.S. Again it would help me if you took a short time to put together something that describes the answer you are proposing.
About the role of BA
David,
Let me quote your statements.
*****
This is because you believe Business Analysts should be experts in the business. In my experience the problem you can run into with this approach:
- The business expert is an expert on todayâs business process.
- They lack an open mind to explore new potential processes.
- The Business Sponsor or Stakeholders may not share their views.
When I use the term innovation I mean it in the sense of exploring with the business new business processes.
******
I guess when you talk about the innovative function of BA, you were saying that we should let the BAs play the role of 'business consultant', not only to the project but also more to the client's business operation. This has been referred to as 'business re-engineering'.
If that is the case, have you noticed that you are trying to play the role of god as we have been doing in the last 5 years or so? We are telling our clients 'hay, you do not know how to run your business. Let me tell you how to do it'. We have seen too many ERP projects failed across the world. Actually, the statistics data shows that over 85% of the ERP projects in China and Hong Kong (including the SAP implementations) failed in the last 3-4 years. Many of the ERP projects end up with going to the court.
Thanks
Jonathan
No, no theory here!
"I think Nuno you are still talking in the language of Software Engineering Methodologies, and basically you are still staying on the level of theory."
I don't think so. If you have read my previous post there was nothing theoretic about them. Most of the projects fail becouse the real problems are not tackled or are procrastinated, in other words, is just common sense.
No CEO ever denied me time to listen or discuss something of value to them. CEO's are equiped with really fast brains, they don't want to discuss requirements step by step, or process, this is something that I've learned with ...
"Do you have the experience when the CEOs fall into sleep while you are presenting your Requirement Specification and/or Screen Designs to them?" - Yes
So basically or your QA team is equiped with a test subject fitting the same personal profile as them as I suggested (in the case of your project) or you try to get them involved. Now to get them involved at the same level as others as you pointed out is impossible, so their involvement must be less formal. A 15-30 mins meeting presenting what was done till some milestone on their laptop (you/PM and him) and leave the system installed is more then enough to spot problems, at least in my experience (in fact in the first 10 mins all problems are easily spoted, they are so fast).
"The reason I emphased that the key roles in software project development should not be taken by Software Professionals is that, software professionals have totally different thinking philosophies compared to the people in the real world."
I know, I used to have difficulty understanding even my CEO. The solution was to be like a leach, that is, I would not leave his office until I fully understood what he wanted. If I left before I would not be doing a good Job anyway. I don't care if I'm not that smart :)
I don't understand in your reasoning when tackle the fact that at some point the dynamics of the problem must be translated to a software system. So at some point your so called "dumn" and "inneficient" software professional must understand the dynamics for him to do his job efficiently. In your description, when does that happen, and how can it happen?
"User representatives got their authorities too, in written."
It does not matter, they did not have the authority. What was the profile of this representatives? You have said they where mostly from IT department, and the users where top executives.
"We cannot do things and think like mathematicians any more. (Well, some of us can. These people are the software professionals.)"
Yes, we can't use our left brain all the time in order to be fully efficient. Most software professionals have a lazy right brain. So that is why we (software professionals) get puzzled when authorization documents do not mean a thing when the "rubish" hits the fan.
"In the end after these 20 years, we suddenly found that we cannot simplify the conditions and environment to provide solutions to the real world."
Yes we cannot simplify conditions, that is why probably in your case the CEO's should have been involved in the QA in one way or another.
You are arguing that everything was done based on sound Engeneering principles of some SDP. So basically some test subject fitted more or less the profile of the CEO (Some MBA, PHD in finance, 4 children, etc etc), so as far as I understand you, everything in that project would have gone better if this person was managing the QA process (a Key Role). I don't understand why and you are not explaining why.
"In the end after these 20 years, we suddenly found that we cannot simplify the conditions and environment to provide solutions to the real world."
Whatever SDP you can list, is not a prescription. One can only absorve this in our minds if we fully understand the process and its impact (requires the right braing). Your next book, if it will be about a new SDP and project managemnt even if based on a new break through paradigm, the same will apply too.
"By the way, all steps you mentioned in your post was followed by the team, because the team believed in Software Engineering Methodologies. User representatives got their authorities too, in written."
I think I already gave my two cents why the project may have failed. IMHO it does no mean for certain that the SDP selected for the job failed, or that the QA methodology failed, or the roles where not selected right, it may mean that probably a silly mistake (some quick fix, some short cut against critical principles) was done and it did not worked. The human aspect!!
I strongly believe in applyed Engeneering Methodologies. Most of the problems are in understanding those methodologies and in applying them. It requires guts, determination and common sense (experience) to apply them. I've never managed/done projects in the same way twice, but I apply the same principles over and over again whatever is the SDP choosen.
A great book about principles and their impact on effectiveness is "7 Habits of Highly Effective People". Not a book about software engineering.
I have been reading this book from Chrismas (a present to my self) and I must say that is a great book about leadership and effective management.
Well I rest my case. I'm looking forward to your book even if we don't fully agree.
Nuno Lopes
One more thing!
If after the CEO meetings described above they say to me the the end product is not as they required to the point the word rubish is played around, I for sure will not stay there and say yes sir, you are right, we have failed. I prefer to loose a client then to loose my professional integrety!
Nuno Lopes
Where do you live ?
Nuno,
I am just wondering where do you live.
I worked in New Zealand for 5 years; Hong Kong for 5 years and China for over 10 years. At the moment, I am overviewing around 20 projects concurrently in a software company of around 108 staff in Beijing, China.
Maybe you can prefer what you stated ('prefer to loose a client') in US or even New Zealand. But in Hong Kong and especially in China, if you still 'prefer' in that mood, you would not be able to get a job, because you encounter the 'bad' situation in almost every project.
Jonathan
Portugal
Jonathan,
I understand that Asian countries have tottally different management cultures then Western.
I worked in Holland for 2 years, Portugal for 8 and for a 2 years have been doing Product Management of a Product that was sold in Portugal, US, Hong Kong and lately a company in England. I was working as an Interface between R&D, Product Development, and Sales.
So in sum, where number of years is concerned I have half of yours.
"because you encounter the 'bad' situation in almost every project"
All projects have problems. My observation was concerned with the project that you have described, the diagnose that I could make condering your description and how the problem could have been avoided. Now condering this, I have said, that I would walk away if the client (main client was the CEO, not the company) did not collaborate as I prescribed as mandatory after some sensible meetings, and when all was done it would call the product a peace of "rubish". We have different styles of communication, and this cannot be measured. As you know communication is paramount to the success of project at all levels.
I have never faced a situation were the end product was not what the client needed. If you have read my other posts, you would know that I already failed in one project as a PM in my early days.
Now considering this:
"you would not be able to get a job" - In Hong Kong/China
I would never walkway on a project were I could see that the reponsibility was mine. If I was the PM of the project that you have described, that would be the case.
Just to clarify, yes, in your project I would not walk away becouse it was not the clients fault as far as I can see it.
Nuno
PS: The company that I was working as a Product Manager, we had clients in Hong Kong (Pharmaceutical).
Should Universities teach software engineering?
TrackBack from Thinking Out Loud: Thought Leadership from an Enterprise Architect: