Nueronic Consulting

With these next few posts i will outline a number of techniques,tools and models that busienss analysts use during the problem investigation,requirements analysis and design phases.

C.A.T.W.O.E
C-Customer: the beneficiary of the business system.
A-Actor: the people who perform the tasks in the system.
T-Transformation: the core activity of the system, or the primary change brought about as a result.
W-Weltanschauung (or worldview): the underlying belief about the system, whether it is the priority, the type of system or the objective of the system.
O-Owner: the person or body that has the power to approve/cancel the system.
E-Environment: the factors outside the system that might impose constraints on how it operates, e.g. legal or regulatory rulings, business environment, workload etc.
[Courtesy of http://www.acca.org.uk]
By identifying these six categories we can have a better understanding of the problem, the key players and the environment in which the new system will adapt to. Using CATWOE, we can identify what each actor in the Rich Picture thinks of the existing system, and the new system that may be needed.  Thus, CATWOE will aid us in better addressing the user needs, and client requirements and form a conceptual representation of the system.

Value Chain
Value chain analysis is based on Michael Porter’s Five Forces Model. This model is used to model the business “competitive advantage” (Porter, 1985) to analyse how value is created in an organisation and to investigate the role of information technology in the value driven activities.
Porter [1985] argued that these activities are divided into two categories:
1. Primary activities. Activities that are used to produce, a product or value.
2. Support activities. Activities that are not directly linked to production but can increase organisation effectiveness.
By analysing these activities, we can specify what value each activity adds to the organisation.
[http://www.themanager.org]

Value Network
Following the Value Chain, I have decided to include a value network, because it is vital to know not only how value is created but also how value flows in the organisation.
“The key to reconfiguring business models for the knowledge economy lies in understanding the new currencies of value”(V.Allee, 2000). Value internally and externally is exchanged between organisations, customers, operational staff, suppliers, partners and the community. But value is not limited only in goods and services, but also includes knowledge (such as, business strategies, business processes, policies) and intangible benefits (such as, customer loyalty, brand name, satisfaction etc).So in order to capture these values a Value network must be applied to incorporate these values so that we can have a full picture of “what is going on” internally and externally in the company”, I identify problem areas and try and enhance these by providing a corrective solution.

There are a lot of reasons why your software project has failed. It seems that it is in our nature to not be able to learn by other’s mistakes.I know software engineering is a new science and relatively young however-there have been so many failed software projects that we can at least see those paradigms and take measures to prevent or at least minimize the chance of it happening to our project. I am going to divide this into two posts. Part one will be the classic/typical reasons the other post part 2 will be focused on my experience-think of it as the “i told you that would happen but you didn’t listen to me list”.

The classic reasons are:  
• Unrealistic project goals. Meeting clients expectations is one thing- loosing money just to get the project is a different situation. Set real and achievable project goals. Proper managers can say to their clients what their teams can and can’t deliver in a current time frame.
• Unmanaged risk. Risk in all software projects is important. Managing it is a quality few companies and individuals have.Thinking it wont happen to us is wrong and trust me it probably will happen. Preventing and avoiding risk or even accepting it after it happens can help you save a project rather than not having the means to deal with the situation at all.
• Failure to understand requirements. Sometimes documentation is good.I know the whole agile principles have take the software world by storm but not making any documentation-even some modeling some use cases and setting feedback loops with the client to me is one of the most important reasons why your software will fail. Defining the requirements properly can save time and enable developers and Project managers to focus on additional items.
• Failure to communicate and act as a team. Team work and collaboration is a fundamental principle. If individual members do not work and function as a team then your project will fail.
• No support.Provide guidance and support to all team members. Moreover executive decisions, action plans and client management has to be taken care of by senior management. Developers will have a lot to do and will not have time or resources to deal with client or other project concerns.
• Inappropriate skills. Team skill set is important. If members of the team do not have the skills required to bring the project to a successful close then your project will not be delivered on time and the company will most likely end-up taking a hit on costs and resources.
• Lack of User Involvement. When we say user, we mean the client. Client collaboration and involvement is very important. Many clients do not have the time to be constantly involved in this porcess and some companies do not afford to loose clients-for economic reasons. Some companies like Thouthworks (if i ma not mistaken) do not take on project until the client has agreed the project methodology, e.g constant customer involvement.
• No feedback. Supports the above. Customer feedback and testing is a success/fail factor. IT companies must constantly chase clients for feedback whenever the latest release is ready.
• Failure to manage the change required. The IKIWISI (i know it when i see it) phenomenon is all-to well know to a lot of project managers and business analysts. How you manage change requests is whole different issue. I suppose there is always a limit to how many change requests you can accept per release. Clients need to be aware of that; I have seen several times the phenomenon of clients contacting directly developers for a “tiny change”. If you put all the above and tie them together you can imagine how this can affect the entire project.

There is more to this list.

Feel free to add your own in the comments