Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'm taking a course in software project management and right now I'm writting a "quality plan"... We've discussed ISOs in class, and I would particularly like my fake company to say the project complies with ISO norm 9126.
The thing is I don't really know what that means. Is it just something you say to your client, does your company need to be affiliated under some international organization for standard compliance, do you have to have your project audited? How does it work?
By the way, if you have any tips on what I can say I'll do to guarantee project quality, just tell me.
Edit I know what ISO 9126 is, what I don't know is who's is responsibly to certify you, how do auditory works, or if auditory is at all necessary (if the project is small does it suffices to show the client you met the goals you talked about when applying ISO 9126?)
ISO qualification is all about making sure your company does everything in it's power to ensure a quality product. Quality is a broad term, but in actuality, what an auditor usually looks for to see if your company is ready to be ISO certified, is that mechanisms are in place to guarantee that a product does does what you designed it to do, and that you have verified that before your product leaves the door.
These mechanisms can be all sorts of things... but really start with a design plan (a list of WHAT your product will do), and a test procedure/list (to see if your final product/output does what the design plan says the product will do when it is complete). A lot of companies have things in place between these two steps, but the input/output steps are most critical.
Does your shipped product do what you designed it to do?
An auditor has to come in to certify you. There are various companies that do this. You can not simply say you are "ISO 9xxx certified". The auditor will give you a certificate. There are different types of ISO certification. And even after the certification, you get re-audited to keep your certification. The goal being that your product and the processes that guarantee its quality improve over time.
Wiki much? http://en.wikipedia.org/wiki/ISO_9126
Not sure but that looks to be a wealth of knowledge there on what you are asking.
ISO 9126 is an international standard
for the evaluation of software
quality. The fundamental objective of
this standard is to address some of
the well known human biases that can
adversely affect the delivery and
perception of a software development
project. These biases include changing
priorities after the start of a
project or not having any clear
definitions of "success". By
clarifying, then agreeing on the
project priorities and subsequently
converting abstract priorities
(compliance) to measurable values
(output data can be validated against
schema X with zero intervention), ISO
9126 tries to develop a common
understanding of the project's
objectives and goals.
The standard is divided into four
parts:
quality model
external metrics
internal metrics
quality in use metrics.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
It is a well known fact that IT projects fail with an alarming rate (some surveys suggest that the failure rate is more than 60%). Typically, project managers try to "recover" from these failures either by squeezing their resources to work extra hours or by compromising the quality of the deliverables (reduce testing effort, reduce scope etc.). Unfortunately, software quality is not deemed as very important by the business leaders.
I wonder if this is true about other professions as well ? How are projects managed, for example, in the construction industry where the cost of failures is very high and where a single mistake can be catastrophic ? Mega engineering projects like the Eurotunnel and Petronas towers required thousands of people and billions of dollars to construct and yet most of these projects were completed successfully within or sometimes even before time.
Are there some lessons we can learn on how projects are planned and managed in other industries ?
I think the biggest difference is that they would never consider starting a project with the same kind of shoddy requirements we are given. Maybe we should stop doing so as well and force people to actually define what they want before we start trying to code it.
I wanted to add that we as an industry to a lousy job of pushing back with a new timeline and budget when the requirements (such as they are) change. We started to do much more of this pushback here, telling the customer how many more hours (and more money) the requested change would take, adding the two extra days to do the the exisitng deadline and making them formally put in a request for change. The number of requested changes to intial requirments dropped drastically once we insisted there would be a cost for the change. This change also moved us from a cost center to a profit center in the company as we were doing a lot of extra work but not charging the customer more than the intial estimate.
Let's take a bridge as an example, and compare it with software.
The bridge will have fewer external specifications. It will have some pretty exacting specifications, but a lot of those will be internal (such as material strengths).
It will be designed by people who know that bridge design is not to be excessively rushed. In general, civil engineers will get more respect from their management than software developers. The civil engineers will in addition be working in a much more constrained problem space. There aren't nearly as many ways to make a bridge as an inventory system.
When the design is done, one or more licensed professional engineers will sign off on it. This is accepting real responsibility. (Alternately, no PE will bet his or her license on its soundness, and the design won't go anywhere.) This doesn't happen in software, partly because the problem space is so unconstrained.
Finally, the bridge will be built, and this will take months and a lot of heavy equipment. Software will be built initially with a compiler and reproduced indefinitely with cheap tools. There is a great psychological significance here: people tend to think of projects as having significant design and significant manufacturing stages, and if manufacturing is too trivial tend to think of part of the design as manufacturing.
If software were to be more like civil engineering, we'd need standard practices, adequate and reliable, for most things. We'd need engineers to study those practices, and be willing to certify that software either was or was not designed properly, and in fact we'd need projects done according to those practices to be almost completely reliable. We'd need more formal assumption of responsibility there. We'd need more external respect, because managers that will not dare throw away a $10 million construction project by meddling will often have no qualms about messing up a $20 million software project.
In short, software is too immature a discipline to work like civil engineering.
A lesson that can be learned from engineering: respect the non-functional requirements.
Functional requirements are hard enough, as they expect the users, developers, analysts and anyone else involved to be able to define what is needed to do business.
Non-functional requirements are the things engineers and technical people come up with that functional people may be blind to. It's very easy to overlook or downplay the non-functionals. Some PMs I've worked with in the past did not want to hear about non-functionals because they couldn't directly be tied to business needs and introduced tasks that would threaten the metrics of "on time and on budget".
Example
Functional requirement: Luxury ship must be able to carry X amount of passengers
Non-functional requirement: Ship big enough to carry X amount of passengers needs to have hull Y units thick to sustain integrity even upon impact with icebergs
Counting the Cost
Why don't software PMs respect non-functional requirements? Because the cost for such disrespect is different for engineering than it is for software development.
Cost of disregard for non-functional requirements in my ship example: loss of life.
Cost of disregard for non-functionals in software: some wimpy thing called technical debt, which will later be paid for by people long removed from the project team and the project team's completion bonuses.
Granted my examples are simplistic. Not all engineering foibles lead to death while some faulty software certainly can (avionics, medical, or traffic control systems being a few examples). But I think you get the idea.
There is a difference between software development and engineering or contruction industry - a specification always can be changed.
Walking on water and developing
software from a specification are easy
if both are frozen.
-- Edward V Berard (from here)
You can find more detailed explanation of differences in approach to project management at the beginning of the "Extreme Programming Applied" book.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
As we are a small company, I work as both a project manager and developer. The specifications I create for clients contain a number of elements used to describe and define the project, including user stories alongside any other elements I feel need to be included to define the project (e.g. wireframes, userflows, sitemaps etc.) to the client.
If a functional specification “describes how a product will work entirely from the user's perspective. It doesn't care how the thing is implemented. It talks about features.“. Then does anyone see any problem with using User Stories to define a functional specification for a website? Does anyone actually do functional specifications in this way?
Really I am trying to up my game a little, and wondering if this would approach would work for larger clients who perhaps have more stringent ideas on what a functional specification should contain, whereby a formal approach may be required. Definitely at the moment our clients respond well to our method of producing documentation.
I am interested in hearing what people who do project management professionally think about this.
I'm at odds with what a couple of other people have said.
First up the bit I agree with - stories are a great way of stating functional requirements. For my money they're one of the best ways of actually communicating requirements in a way end users will really take in. I've seen too many specs that get signed off without ever having been read.
The one thing I would say you might want to append to them is non-functional requirements - covering performance, security, data volumes, audit, archive and so on. While they can be covered in stories, sometimes they're better covered in a way that crosses all stories.
In terms of whether it's suitable for large companies this is where I disagree. In my experience (and I've done projects for Shell, American Express, a couple of multi-national banks and others) they're often no more formal than smaller companies so they'll be fine with stories. The reality is that a user in a large company is no better equiped (or interested) in reading class and sequence diagrams than they are elsewhere.
The size and complexity of the project may require more detailed requirements but it's the size of the project, not the size of the company that matters when you're determining how you document requirements.
For me the best requirements documentation is documentation that's suited to it's audience, and for me user stories hit the nail on the head most of the time - they're short enough and clear enough that when they sign them off they mean something because they've read and understood them (as opposed to the sign off of a 100 page spec which invariably means they haven't really read it), but good enough for the developers to work from too.
Yes, you can use user stories for your functional requires. I do it all the time, and have been for years. In my opinion, it works really well, and better than other systems I have used.
Would this approach work for larger clients? To make a gross generalization, no. They are going to have some system that use to define requirements, and likely its not user stories. If you come in with user stories, there is going to be a disconnect with the current practices, which you will have to work through.
I have been successful using user stories with larger organizations, but it take a concerted effort, which both parties need to be committed to.
What you're describing are the use-case scenarios that define the features, this is what is required from a usability perspective and is exactly what the client will understand and agree to. Screen mockups and flow diagrams will definately help both the client and developers.
An implementation specification may then be required to instruct developers on what needs to be included in the actual construction, the depth of this will be determined by your developers capabilities that include their knowledge of the house architecture/framework and methodologies/conventions and may include specifics on what impacts various parts of the application.
We also work in small teams (sometimes one or two developers) and believe the above is all that's required in this instance.
Larger companies with much larger teams may use Modeling Software, UML diagrams and other more detailed specifications. In the case where you the primary developer, you should still spend the time designing your application, but if nobody is going to review the designs and insist on all the formalities, your time is better spend implementing the software.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Based on what criteria they choose the projects and what are the things based on which they choose a project...?
Return on investment, if they want to stay in business.
Return on investment is ofcourse the final product. But it takes a number of factors to get there:
Their own expertise: Do we have people with skills needed to do this? Can we hire some?
Available resources: Programmers, Managers, Hardware, Time, Financial resources.
PR: Even if we dont get paid that much, will this project get us more business?
PR: Pay is great, but do we really want to be associated with this client?
Their Mission/Goals: What fields/niche do they want to compete in. Do they want to expand?
Past experiences: We did a project like this, it was horrible. Lets not do that again.
Past experiences: It was fun last time, AND we can reuse half the code! Lets do it!
Usually the management uses more sophisticated matrices and all to make their decision, but more or less, these are the factors they usually put in.
I am sure someone can provide a more specific/scientific answer.
Good question. The straightforward answer may seem to be Return on Investment (ROI). However, ROI is criticised for three reasons:
Short-termism: ROI is seldom calculated beyond 5-7 years (due to increasing discount rate on any cash flows produced in the future), some projects really worth doing realise full benefits much further in the future.
It’s hard or impossible to put monetary value on some things. The often cited example is human life. The other is moral principles. However, most frequently encountered thing in software world what is very hard to put a price on is opportunities that will never emerge unless this project goes live. It’s hard to put a value on the emerging opportunities, because we don’t know what they are until they actually emerge. And I don't mean opportunities that will simply not “open”, but specifically emerge.
ROI doesn’t take into account wider strategy. The importance of strategy in software world should not be underestimated and the strategy should take into the account specifics of providing software products or services. Geoffrey Moore’s “Crossing the Chasm” is a brilliant book I recommend and is very pertinent to the software world.
Joel’s recent instalment “Fruity treats, customization, and supersonics: FogBugz 7 is here” has a great sample of strategy document and the reasoning behind it. It seems that FogCreek plans to leave the bawling valley and enter the tornado (according to Geoffrey Moore’s classification) with their FogBugz 7.0 and hence the strategy of removing barriers that prevent people from switching to FogBugz, instead of spending time to introduce some more vertical features.
Other tools that can be used for selecting projects are SWOT analysis, Pareto analysis (i.e. choosing a project to address 20% of causes that are responsible for 80% of problems), PESTLE, Cost-Benefit analysis (similar to ROI, including the critique).
However, it seems that a sane strategy that states that the company is planning to do and not be doing in the finite period of time (often next year or two, in high tech market conditions are hard to predict beyond that horizon), gives a simple guidelines for choosing priorities and clear direction for joint efforts is the best starting point.
I also recommend reading a fabulous book “Almost Perfect” by Pete Peterson (former CEO of the maker of WordPerfect) that is available online. The book tells a real-life story of different strategies SSI Inc followed, some planned and stated and some ad hoc, and the way they were used to select what to work on.
ROI is only one measure. There are many other factors:
Risk management - for example, improving the process may not show any direct return on investment, but by adding e.g. unit tests the quality of the software can be improved and risk of a production bug reduced.
Compliance - there may be requirements by industry or government that need to be followed. Directly this may not show a return on investment because they may never be audited, but the downside to being non-compliant is huge (being shut down).
Manageability - providing metrics on bugs, project schedules etc. may not show a direct return on investment but it may allow them to better predict and manage their projects.
Security - this may be considered as a part of risk management, but it is a broad enough area to merit its own category. Making legacy code secure can cost a large amount of money and not show any immediate return, but there are obvious reasons why this is worthwhile.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
What are the best practices when managing a software project involving a non-English-speaking client?
What communication issues are relevant? Would you maintain documentation in both languages (especially updating the specifications regularly)?
The basic risk in such type of projects is miscommunication, so the top priority is
validating the understanding of both parties, i.e. you should not only validate that the customer understand what you say - you must also validate that you understand what the customer says. Then, with the explicit goal of validating communications and based on the resources you have to understand your customer's language and the resources your customer has to understand your language, you and your customer shall agree on how to handle communications for the project: documentation in both languages, single points of contact, written minutes of all communications, translation of all communications, etc.
To minimize the possibility of misunderstandings, it is better to have all official communications in just one language, if possible. If communications shall be held in more than one language, you must minimize the number of communication channels, i.e. you must not have everybody communicating with everybody else: liaisons should be designated to handle all communications. Single points of contact with known proficiency on the language(s) used in the project are crucial.
Casual communications shall be avoided. All conference calls and meetings shall have written minutes describing all agreements and action items - if multiple languages are being used, all minutes shall be translated by a single party and reviewed by the single point(s) of contact.
The practices I have just described, may seem an ugly burden to bear, but they will prevent a lot of headaches.
Good luck!
My native language is not English, so I'm on the other side. There were times when we had to write project documents in 4-6 languages.
Try to find somebody who understand English (like a key person). I try to avoid the communication in different languages on a project. Of course you can talk and write on different languages with project members, but if you talk or write to all members of the project at once, it should be one language.
Documentation should be maintained in as many languages as many involved. All documents should be updated on a regular basis and try to avoid the situation when you have to tell them that "the English is the current one". Find someone who is native in the target language and translate from English for you. It will be far more better, understandable, and more native than if you try the other way around.
This might be the perfect case in which you might want to switch over to Agile development. This puts less of an emphasis on large amounts of documents and you can provide work at the end of every interval for the customer to sign off on. If you don't know what Agile is, just google it, you'll get tons of information back.
Always follow up with a written confirmation of any verbal discussion. Most people can read foreign languages better then they can speak them. It also helps to pick one language as the standard for all documents and code.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Probably an easy one:
Are there any rules of thumb or pointers that could help recognise political requirements?
Let’s say one of stakeholders (your boss, a head of another department or an actual user) asks for a feature or particular characteristic of software being developed by yourself or your team. Is there a litmus test to determine whether requirement is political?
This question is really simple and is not about how to deal with political requirements or whether they are bad or good for software. How do you tell that whatever you have been asked to do is to pursue someone’s tacit or actually openly stated political agenda?
Will it really help you to know? I mean - if you're already embroiled in political games you'll know anyway. If you're not it isn't something you'll be able to use.
If you're going to have to implement the feature anyway I'd say just get on with it. Finding out that it's part of some management game will only demotivate you.
That said - if you're working on the sort of application that's so themware that you can't tell whether it's a real user feature or a political lever of some sort then it's probably a safe assumption that everything is political.
I would say that you should assume that all requirements are political.
If you are in a situation where more than one person is responsible for determining the set of features you implement, then every feature is effectively a negotiation between those people. That negotiation makes those features political.
However, even if there is only person deciding what features ship, there is still a pretty strong chance that those decisions are political. In any organization of reasonable size (say more than ten people), you are going to have politics. The politics in that situation will differ than the "design by committee situation". They will focus on currying the favor of the person who decides which features ship, rather than on "if you support my feature, I'll support yours" that exists in the committee scenario. That process, however, is still political.
I'm not trying to say that it's not possible to have a development environment free of politics. It is. However, I would say that to pull of it off that you need:
A small, tightly knit team
A boss that focuses on creating an environment that fosters creativity, and delegating creative ownership, rather than focusing on control over the creative process.
Smart, highly talented and creative people that share a strong sense of purpose and aesthetic values.
Missing any one of those things, you are doomed to a repetitive deluge of office politics.
The best idea is to find out what all the features are to be used for, i.e. find out not only how a feature is to be implemented, but also learn why it should be done. It really helps to know the background of the desired solution. It might even allow you to suggest an alternate feature set that might better suit your customer (maybe even play your own political game).
As long as there is anything you do not understand, do not do the project. It will only cause problems at some point.
Obviously it's a tricky question and much depends on your definition of the 'political'.
I would start with the simple question:
* Are the authors/originators of the requirement really using the software in question?
The requirement could come from your boss but it could be a translated valid requirement of the real user
Here are some I've seen:
It directly contradicts other requirements
It is clearly not feasible technically
It is "out in left field" ... it doesn't fit into the defined problem space
It contradicts common sense
BEWARE ... sometimes this results from your use-cases being wrong or incomplete. I've also purposely allowed some of these to proceed to development (e.g Eye-candy that sells the product but is useless or at least generally not used by the operators).
Use the SCRUM approach. Don't describe a feature as
"It should be doing this and that in the following way"
While the sentence above describes all you need to know to implement the feature, it does not justify the feature. My SCRUM book says features should be written down as a story. A story looks like this:
"As a <user-role>
I need a <functionality>
So that I get <business value>"
A feature that cannot be justified using such a story is an unjustified feature and thus there is no use to actually implement it.
E.g.
"As a visitor of a web portal I need a way to authenticate, so I can access my customer data, but nobody else can"
Now you don't only know that you need an authentication for your web portal, you also know who needs it (the visitors, basically everyone planing on using it more intensively) and you also know why it is needed, as it gives the user some value.
Other examples:
"As a passenger I need a list of all my booked journeys, so that I know when I'm going to travel where and won't lose the overview"
"As a book keeper, I'd like to have the sales tax being automatically printed to each bill based on customer data, so that I don't have to enter it manually each time I'm printing a bill"
If every feature needs to be written like that, you'll automatically see if a feature is for the customer, because it is really necessary, or just something your boss/company wants to have and also why they want to have it (what is the big picture behind it? Why are they doing it?).
The use of ambiguous words or phrases is often political.
However,
Never attribute to malice that which is adequately explained by stupidity.