Requirement, user and developer ....

Irrespective to the improvement of software or hardware, what is crucial is and is to understand is, the challenge that need to understand to users, in terms of their requirement, what is currently receiving and what they expect more.

Software Development Life Cycle, in what ever application may be is the core basis for functionality any IT  Company. Outsourcing is an important part for the industry and heavy tendency in resorting to outsourcing significantly, complexity of the said process increases and naturally risk factor also goes up. Given the circumstances, developing an application outsourced, raise the importance of the Requirements, its gathering and design and not fall in not meeting user expectations when it is too late.

The most critical change, however, is the participation of a more sophisticated and unknown user: the consumer. He or she not necessarily be the front face of the organisation but an individual who will be the owner of the system, thus makes him the most unusual individual: he/she does not participate as part of an internal organization, or external client, rather a transactional force at the beginning and later the owners that comes in and out of the application with an enormous amount of uncertainty and constant change in behaviors and needs. Organisations rely on these individuals in determining the viability of the system to proceed with.

It is imperative that we expand analysis and design through SMART requirements in to provide developers from inside and outside the business to clearly understand what is needed thus enabling them to deliver the required.

Applications need to change more often, so that object-based design is no longer an alternative, rather a necessity to allow organizations to continually evolve and mature their abilities to serve their clientele.

Sealing the deal!

Every project has different stake holders. it is difficult to find projects which has single stake holder you can count on.

success of a project lies on the implementation to its fullest, which is basically fulfilling the needs of all the users who are going to use it.

we may not be able to fulfill and as a matter of fact we may not be able to figure out all the users as well.

but every project is run by set of users, we could easily categorize them effective users, whom are front faces    of the project. getting their acceptance is naturally considered as the final.

The lesson will be learnt, if we lean into a set of users and do not cater needs of another sufficiently. Now you may put your faith on your favorite users, but when comes to official stamping off the project, users will be looking for much more than the favoritism shown to them.

So the rule is identify your effective users and make sure testing is done by all those users and their signatures are collected as evidence.

Process A to Process B

Recently, i went into some trouble. Not for some design that i have done but design someone else has done. Yet i'm responsible, (which is something, i would like to discuss more later).

A vital process did not get executed, but was not known until months passed. Process so important, once a min owe thing has gone in to proportions, needless to say putting me in great trouble. 

My CEO taught me and/or reminded me something, that i would like to keep in mind rest of my career. Processes are sequential which means one depends on another to finish to start-up. this is a continuous process which ends when either meeting the target or ended up in error and terminates. 

What should be happened in between two processes, where one is taking control from the previous one. One thing and one thing only, it should pass the ownership. previous owner should make sure it has passed to the next with confidence of completing successfully its objective and current owner should make sure that he received the control with no strings attached, another words no errors or issues been inherited.

Suppose there are errors in one process, rather progress with hiccups, inaccuracy and inefficiently, it would stop just limiting the situation to mere convenience rather than to a cut-throat blame game and data corrections. worse things could happen to a designer.

let me summarize you in simple graphical format.

Requirements 1-0

We rely on requirements have our designs. Designs are results of processed requirements. that it self shows the dependency our designs relies on requirements. 

so undoubtedly, requirement gathering is the most difficult aspect of software development. Every other stage in development cycle is made difficult by our actions. Specialty of requirement gathering is it contain elements of surprise or/and actions goes beyond your control.

No one is supposed to collect the all the requirements or in a perfect way and it is not human nature to achieve such good results.

But there is one thing that we all can follow on with respect to requirements. Irrespective of whether they turn up to your face before, during or after the cut off date, there could be only two statuses. 0 and 1. 1, you know about it or 0, you don't.

now not hard as it looks right, but it gives you the base line for next course of actions. how do you identify it is either 0 or 1, is just being thorough with the requirements you have collected like no one including the very people gave you the details, should be able doubt you.

biggest danger or risk, a designer would mount on is, developing a doubt about your own work. once let that come to you, everything else would be easily be fallen apart.

Thing for humans

human interface design is a hot topic going around.it makes sense we are making systems for humans.but considering different nature each human posseses,big question remain as how can we generalise all to single interface that to serve all.
now i think it lies on the experience and mainly it is domain specific. in more detail, the right interface for a system depends on the ability and likeliness of the members of the organisation to "mingle" with the system. that depends on the capability and desire the members and as an organisation drives on.
see it is not always easy to address things bases
d on generalised term, things needs some tweaking titching once in a while

Designing for internal & external

Recently, I was to undertake a project more like a mini one which involves dealing with your internal organisation structure and external parties as well.
Now, reason for this thing to be special, i must say, is i had to treat my internal correspondence to a level of external due to standards they are following. Argument over the standards, keep it aside for a while, but this exercise has taught me some good lessons in understanding the approach needed in advance.
You have to have a design in mind even you are deal with ones inside the organisation. You are portraying your self as the custodian thus requires you to be concrete on your design.
so when we approach for designing, it is required to remember the outlook you should be portraying to your internal organisation structure and to the outsiders.

Connectivity between IT and Business

What would system and interface design has to do anything with connectivity between the IT and business ? it has a lot to do with it. Interface and system design is for the business, developed by the IT. so it is all about the connectivity when deriving at the perfect design. it is a well understood reality in world of TI, where either you tell the customer to do or you do what customer asks. Both instances have worked in the IT industry, which makes both are good approaches provided the best strategy is adopted.

Following are some of the ideas, that one could employ in achieving the success of design implementation.

1. Strategy for both IT and business should be similar and shared. it is imperative that, when both the parties quest for the same goal, shared and similar resources, actions, methods etc etc are the keys success.

2. IT and Business should talk in same language, which means, both should understand that what they are deciding on, act on and implement on.

3. No two humans can achieve their heart desires at the same time. there is no change for the world of IT, where both the IT and Business must willingly, compromise and collaborate.

4.Alignment and understanding in execution of planning, structuring and implementing of the project as a whole is a must. This whole execution process is a collection of resources which supplies the skills, communication, negotiation etc.