A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Getting a clear decision making process and implementing it to prevent rework – Part 1

When you have multiple stake holders in a software team (and most people involved in the development process like to think of themselves as involved, especially the more passionate and dedicated ones), there can be a lot of active discussions and with people expressing their views (and depending on the culture of the teams, some of these disagreements can be loud and may seem very disturbing to outsiders). However, if there is not a proper decision making process in place and this is acceptable to the team members, things can get very messy very early. I will list below (and in a subsequent post) some cases where these disagreements have a clear impact on the team schedule and effort, and can be very confusing for many members of the team. It is imperative for the management of the team to ensure that such cases are rare, and if they happen, then the cases should be looked into and if necessary, policy changes made.
Consider a case where a feature discussion is happening regarding the UI of the application. Now, in such a discussion, you would typically have a set of the team members, you would have the experience designer, and you would have the Product Manager. The boundary line between the experience designer and the Product Manager can be tricky, since the Product Manager is typically responsible for ensuring that the right set of features make it into the product, and towards this end, the Product Manager defines the requirements, both in terms of broad level feature requirements, and individual user cases that outline the various set of workflows that must be satisfied as part of the ultimate feature. So far so good.
The experience designer is responsible for ensuring that the UI and workflows that the user sees while using the feature are as optimal as possible, in order that all the workflows given by the Product manager are met, as well as the set of screens and other UI elements that the user experiences are the optimal experience, and that the user finds the feature easy to use. Together, when the experience designer and the Product Manager work well, you can get a great product that is a winner in the hands of the user. This plays a role in the success of the product (although there are many other factors that go into making the product a success, but if the users do not find the features usable, then it is hard for the product to be successful (it is is a mainstream product)).
Now, it is the interaction between the responsibilities of the experience designer and the Product Manager that you can get into huge conflicts that have the potential to screw up the successful development, create bad blood in many cases, and need management intervention.

Continued in part (2)

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>