What it means to take initiative

Taking initiative is Courage to take challenges beyond the purview of our day to day work. Doing day to day work is business as usual.Every individual has his own unique strong points. Taking initiative is giving the best to what you are good at both outside and as a part of your day to day work. For example, if you are a good musician, you can take initiative to build a music band in the organization. It is as sstraighht forward as that.

I believe every new heights made by an organization is a result of initiatives taken by one or other employee in the organization. Extrapolating this theory, if everyone takes conscious decision to take initiative to explore best in self and there by contribute to the organization, the power of organization to scale new heights will be enormous.

The following are some thumb rules/basic lessons I learned from various initiatives I could take.

  1. Once started, under no circumstance, one should drop the initiative
  2. No reason for backing out can stand before us, if you are strong like a rock. Instead only our discipline will make others feel that the initiative is longstanding.
  3. Our commitment to the initiative will be time tested.
  4. Our commitment will also be tested by others first before they welcome the same.
  5. Keep adding value to your initiative.
  6. Take it for granted that there will be criticism. Combat it with the belief that you know the best on what you are doing.
  7. Welcome criticism with an open heart, weed out the emotions and understand the core message, analyze if there is any key takeaway for you, do the mitigation.
  8. Believe that your initiative will be a huge success.
  9. Believe that likeminded people will slowly start accepting you as a leader and will start following you.

Once you have initiated an activity, it is no more an initiative, it is a live program. Hence to keep it alive on an ongoing basis, you need to instigate life in to it by way of introducing new strategies and new people centric sub initiatives.

An initiative has to be nourished and re invented through multiple other small initiatives until the initial objective is met. It is also quite possible that you find larger purpose/benefit out of a small initiative that you have started off. If you ever find it that way, redefine the objective of the initiative there by taking it to new levels.

Last but not the least, an initiative calls for a lot of perseverance from the initiators and support from the beneficiaries. The result of all the hard work will be directly proportional to the gravity of the above 2 factors. It is imperative that one cannot live without the other.

Now step back and we can see that at any point we are always a part of an initiative – either as an initiator or as a beneficiary. Choice on to what extent we should contribute is always with us. But doing the same with awareness is highly important and is mandatory.

Doing Business Analysis Better - By Prototyping Screens And Workflows

Any software or technology, in it's final form, is expected to solve a business problem for an end user. And hence, it makes perfect sense to enable the end user to validate the system before the actual construction - to ensure that there are no surprises in the end.

Yes, this sounds so obvious, but it is often amazing to see how teams neglect such a powerful technique like prototyping. Prototyping the user interfaces and workflows early enough will ensure
  • There are no release time surprises
  • Requirements are captured properly
  • There is clarity in functional scope (in scope and out of scope)
  • Analysis is good enough to start the construction phase.
Why you need Prototyping?

Let us take an example. You are a business analyst. Assume that you have a whole-sale carrot distributor as your customer, who is owning the company "Thick Red Carrots" and he is having a requirement.

"I need a simple program to manage the distribution of carrots I purchase from my suppliers. I also need to view and track the location of all my sales guys in the field; to know the number of shops they are covering a day, and to track the number of carrots they are selling in each shop. I also need the software to give my tax statement from my sales data"

When you dissect the requirements for this 'simple' software - obviously you can see the scope is increasing. And after several rounds of discussions with your carrot whole seller, you understood the actual requirements - still on a high level.

Briefly, the system should include
  • A user management and payroll module to enter and manage sales staff details.
  • An allocation module to allocate a geographical boundary for each of his sales guys on a daily or weekly basis.
  • A module for interfacing with sales guys - the sales guys will use their mobile device to enter the collection data back to the system, from the field.
  • A supplier management module
  • A stock management module to track the in house stock, allocated stock etc to foresee and report possible stock deficits
  • Admin module to enter master data - including employees, stocks, suppliers, shops (customers) etc
  • Reports for reporting all this
You also found that you need to address specific conditions, like overlapping of sales regions, back-collection of damaged carrots etc. Gasp. Gasp. Gulp, Gulp.

Prototyping To Help

You have several challenges. To mention a few, you need to
  • Make sure your carrot seller understands the features required for the final system, so that he won't cry about the scope creep.
  • Ensure your design and development teams are understanding the requirements, so that they won't miss out any functionality, and at the same time they won't over engineer.
  • Ensure all workflows and specific business cases are documented
  • Ensure all customer expectations are clearly identified and captured (remember, the tax calculation part)
You turn to a white board, and start visualizing the screens and user actions. (For an illustration, I'm using http://www.balsamiq.com/ for some quick drawings). You decided that the main screen should allow easy navigation to all modules, and hence should be having a tabbed interface. The entry screen will display a summary of statistics, and will may have few quick links as shown.

You go further, and sketch up few individual screens as well, based on each requirement. To enable the end user to define sales regions, you might create a user interface with a map - so that the end user may draw a sales region with in the map, to specify the allocated stock for the sales guy to sell in that region, and the date of allocation.

With these sketches, you might goto your end customer, and take him through these screens. You might get straight forward comments like "The dashboard screen looks awesome, but I need to view my current stock there in numbers". Few comments might definitely alter the scope, like "I need to import my employee contacts from outlook".

And once the end customer agrees on the screen protoypes and how he may switch back and forth between them, you are good to pass it to your design and dev guys, to take it to the next step.

Another key point to have in the back of your mind - When you present the prototypes, make it clear that it is just a wire frame to demonstrate the functionality. And if possible, present a real life snapshot of atleast one of your screens, to clarify your point.

Tools for doing prototyping

There are various online and offline tools for doing prototyping. You can google around to find a few. I use Balsamiq for quick and static UI prototyping, http://www.balsamiq.com/ - and Microsoft Expression Sketchflow for some serious prototyping.

The good thing about Sketchflow is that it supports workflow prototyping and behaviour prototyping to some extent. What's catchy about Expression Sketchflow is its ability to provide a dynamic, 'clickable' interface for the user - so that the user can get a some what realistic experience.

Significance of Emotional Quotient In Communication And Decision Making

There is only a fine line between flipping from a balanced emotional state in to either getting rude or emotional break down. The so called professional behavior is highly backed by a good emotional stability of a person.

The emotional stability to be able to tackle an issue(particularly people related) very much require a person to rise above the entanglements of feelings and see even his own feelings from a third person's point of view.

One of the techniques I use to take a fair decision is as follows.

When a person approaches me with a people related issue, I approach the same the following way.
  • First job for me is to set my mind clear from other issues that I might be handling. This helps me to stabilize myself in the highly responsible role of a good advisor and conscious keeper.
  • I start with the assumption is that this person has never tried to see things from the other person's point of view. With this assumption in mind, I take up the devils advocate role during discussion. This helps me to test the person's own conviction towards his view points on the issue that he is facing.
  • During the discussion, I verify if the person has already shared his issue with some one in pursuit of some relief. If yes, I do an additional task of delinking the issue from possibly accumulated notions and incorrect resolutions he might have already resorted to.
  • I assume that the issue is going to be presented before me with lot of attached feelings; simply because we naturally have a tendency to justify our doings. And the easiest way to justify things is by attaching feelings with it :-). This helps me to unlock the person from his emotions and think wisely and strategically. I believe that a person will clinch on to is feelings only until he gets an avenue to release it. Once it is released, generally people feel very light and free. I try to be the person who can facilitate the same.
  • It requires an extreme level of integrity from my side to keep the discussion points to myself.
  • After listening to the issue, I give my perspective on how it can be resolved.
  • Even though, people seem to react very positively to discussions like this, I still believe, one discussion is too less a time for any one to take some solid decisions. Enough time is given to the person to do his home work to resolve the issue. Hence irrespective of whether person was open to the suggestions or not, I just end the discussion by putting my views and giving him enough time to think over and assimilate and act.
  • I do not believe any one can be judged with one conversation and hence I too need time to study the case. While the person goes back to his desk taking his own time to work up on the issue, I also utilize that time to study the case and look out for any better resolution.
  • Depending on how the issue resolution progresses over next couple of hours/days, I gear up for the next level of discussion.
  • This exercise finally ends where the person has resolved the issue in the best possible way.

Last but not the least, inviting a person to discussion and suggesting solution is not a kids job for me. It is as serious as taking an important decision in my own life. This is because I do not know how much my suggestions influence a person's decisions. Hence I keep a special attention to ensure my suggestion will do the best for the long term benefit of the person ,Team and the Organization.

Building Automation frameworks using WCF, WF and WPF

From the Geek Session Hosted By Sarvesh

NET 3.0 is primarily made up of WCF, WF and WPF.

The Windows Communication Foundation (or WCF), is an application programming interface in the .NET Framework for building connected, service-oriented applications.

Workflow Foundation(or WF) is a business Process automation framework.while Windows Presentation Foundation (or WPF) is a graphical subsystem for rendering user interfaces in Windows-based applications.

Together the three can be used to build very powerful automated mechanisms for a variety of scenarios.

Automating Deployments using WCF, WF and WPF

Let's take the case of deployment. Any deployment process is made up of several stepsor units of action.Like copying a set of files to a folder is an action.Creating a folderis another action.Deleting folder, stopping services, starting services, configuring app.config files, starting IIS are more examples of actions.

Each such unit of action can be coded into an independent block known as an "Activity" in WF.A set of activities arranged in a particular order or fashionis represented by a Workflow.WF supports both sequential as well as state machine workflows.Thus every deployment process can be represented essentially by a Workflow.

Normally deployments take place on a remote server.It would be very convenientfor us if we could automate or take control of the entire deployment process sittingonto our local machine rather than remote logging or remote desktoping into the remote server.Such a process is facilitated by using WCF.

Every Workflow in WF can be exposed as a WCF Service.Thus by exposing our deploymentprocess first as a workflow and then as a WCF Service we can control our deploymentor other actions on the remote server sitting on our local box.

Finally we would like to have a user friendly interface via which we can controlthe remote deployment and such a interface can be created using WPF(You could alwaysuse a console app or windows forms but WPF is the next generation UI framework and youmay as well go for it).WPF has features such as 3D objects, support of video/media, great features like the ability to mould your buttons, UI Controls into various shapesanimation and more.

Automating Testing using WF and the MouseKeyboardLibrary

Normally testing also is made up of individual repeated chunks of action which againcan be made into custom activites using the workflow foundation.Now every workflow has an XAML(a form of XML) representation.Thus every Activityis in turn represented by an XML Element.By using another .NET Program which can interchange these XML Blocks one would land up with a different testing scenario.Thus testing use cases and testing can be automated.

Of course one would ideally want the testing mouse clicks, keyboard inputs and otheractions also to be automated and this can be done using the MouseKeyboardLibrary(a freeopen source .NET library offered by Codeproject).This library gives us the abilityto hook into mouse/keyboard events and also to simulate mouse/keyboard events.
Thus a WF custom activity made up of calls to the MouseKeyboard library wouldact like a virtual automatic tester.

Using WF Designer to build an Automated deployment or testing framework

One of the less known features of WF is the WF Designer.The WF Designer classprovided by Microsoft gives us the ability to host the Workflow Designer intoenvironments other than Visual Studio.Thus one can have an independentWPF application or Windows Forms application hosting the WF Designer.Such an application would provide us with the ability to design our own workflowsin an environment different from visual studio.

So first by designing our custom activities or units of deployment and secondlymaking these accesible from a WF Desinger Application one has succesfully builta construct-it-yourself deployment framework.Such an app would allow teams having no knowledge of WF, WCF or WPF to build their own deployment/testing or other workflows.

Testing and Deployment are just examples wherein one sees the extent to which WCF and WF can be used for automation. Most of the processes in our organizations can beactually simulated using WF Workflows, most of our interactions with Remote machinesand servers can be replaced by WCF Service calls and our own interaction with ourdesktop can be done using a friendly WPF User interface. Thus the combination of theseframeworks provided by Microsoft gives us a great means to build a wide variety of veryinteresting and useful applications.

Winning BRDs

Before you read this article, please read the introductory post on "The Edge Thought Series".

This post has been compiled from best practices, my experience and thoughts collected over a period of 8 years of involvement on various projects (spanning enterprise-wide ERPs to small shopping cart applications across business domains and technologies) and learning gained from co-workers all along.

The need for 'Winning BRDs'
  • Design and development effort estimates are often based on this phase.
  • Testing (test planning, scripting and quality assurance) is based on the BRD.
  • Disputes during UAT phase (regarding bugs or change requests) often take the team back to the BRD.
  • Business Analysts who create BRDs are often expensive resources and the output needs to be in line with their cost.
  • User manuals/trainings are often structured based on the BRD.

Therefore, Winning BRDs contribute significantly to successful projects.

7 Success Factors - for a winning BRD/Requirement gathering phase
  1. Pick up the scope of work from the signed off proposal document. At any point of time if there is any scope creep at the requirements gathering phase, it needs to be raised immediately to the project manager/account manager, who may want to pitch for it as an enhancement.
  2. Consider the BA phase as the 'only' available opportunity for requirements discussions.Discussing requirements at a later stage indicates either a not-so-good job done in this phase (for whatever reasons), or changing client requirements.
  3. Identify key stakeholders in the client project team. The ARMI (a model commonly used in the Six sigma methodology) works well here. Create the ARMI matrix early on during the requirements gathering phase and get it approved from the client project manger.
  4. Schedule time with all stakeholders in advance and regular milestone reviews with approvers to ensure the progress is tracked.
  5. Think business and not technology solutions while gathering requirements.
  6. It is valuable to have a technical designer/architect on board as a consultant during the Requirements phase. Regular reviews of the BRD with the technical lead can be useful in eliminating delays and rework during the design and development phases.
  7. Know the effort estimated and cost threshold for the BA exercise and constantly monitor the overall effort required and your current status until the BRD is finally signed off by client and internal stakeholders.
Winning BRD attributes
  • First create the broad BRD structure keeping the scope in mind. Then consider each module/section at a time and break it up until no further levels of granularity remain.
  • Pictorial Representations - Work flow diagrams convey much easily and better than pages of words.
  • Concise - Avoid rambling verbose document. Use bullet points wherever possible.
  • Traceability - It should be amenable to track developed code units from the BRD.
  • Output should be useful for Testing-teams and it should help them to build Test cases form it.
  • Indicate clearly the open questions that may have been put into the 'parking lot' during requirements gathering discussions.
  • Capture as many implicit requirements as possible.
  • Research best practises of business processes and technology solutions in case multiple options need to be proposed.
  • Prototyping - Identifying if there is any need for prototyping. Prototyping can be non-functional mock-ups or semi-functional screens in HTML or other such tools.
  • In case the client stakeholders are not clear on what they need, research and question them on any competitive products/systems that can be referred to and build the discussions based on these.
Churning out Winning BRDs takes good jugglery of knowledge and skill from the BA (Business Analyst).

Soft Skills required for a Business Analyst
  • Keen interest in exploring diverse business domains, even really new concepts. The work may vary from requirements gathering for a Supply chain management to a website of a DJ's club!
  • Very good listening skills, without imposing one's own thoughts/experience much while listening.
  • Be a consultant as much as required in suggesting, sharing, recommending or questioning without critiquing the current business environment.
  • High energy levels to facilitate multiple types of stakeholders, but without putting them into frenzy.
  • Ability to convert an out-of-scope i.e., new/changed requirement to change request or enhancement.
  • Fluency in English language and excellent verbal communication skills.
  • Exposure to diverse cultures.
  • Ask the right questions at the right time to avoid rework later.
  • Be an internal client to the Development and testing teams.
  • Need to have Twin orientation - client focused and developers focused.
  • Minute all meetings and seek sign-off from client stakeholders.
  • Finally, patience to work with all types of clients - from the technically savvy to the technology agnostic.You could even get a client who would say that "I love my current process, but I am talking to you because my boss asked me to!"
PS -For the last category, try answering the question WIIFM i.e., what's in it for me!

In my previous post and related codeproject article, I gave a quick introduction towards creating and using your own custom dynamic types, inheriting from the DynamicObject class.

From a business point of view, it might be interesting to examine areas where dynamic features in C# can add value.

I'm just listing down here a few points from the "New Features in C# 4.0" manual regarding scenarios where you may increasingly use it - [Get the complete doc here][^]:

"The major theme for C# 4.0 is dynamic programming. Increasingly, objects are “dynamic” in the sense that their structure and behavior is not captured by a static type, or at least not one that the compiler knows about when compiling your program. Some examples include:.

  • Objects from dynamic programming languages, such as Python or Ruby
  • COM objects accessed through IDispatch
  • Ordinary .NET types accessed through Reflection
  • Objects with changing structure, such as HTML DOM objects"
In this post, we'll dig in further more in to .NET and C# 4.0.

.NET framework 4.0 has a cool new ExpandoObject class, in System.Dynamic namespace. What makes this special is, it allows you to create an object with members that can be dynamically added and removed at run time. To clarify the point, have a look at this example.

dynamic obj = new ExpandoObject();
obj.Value = 10;
var action = new Action<string >((line) => Console.WriteLine(line));
obj.WriteNow = action;

And you'll get the expected 10 as output in your console. As you can see, the property 'Value' and method 'WriteNow' is attached at runtime, when the invocation happens.

The objective of this post is to examine how the ExpandoObject itself is implemented. To make this clear, let us create a MyExpando class, a minimal implementation of ExpandoObject.

We are inheriting MyExpando class from the DynamicObject, and these are the major methods we are overriding.

  • TrySetMember- Provides the implementation of setting a member.

  • TryGetMember-Provides the implementation of getting a member.

  • TryInvokeMember- Provides the implementation of calling a member.

  • GetDynamicMemberNames- Returns the enumeration of all dynamic member names.

And Here is our minimal MyExpando class, inherited from DynamicObject, and overrides the above methods.

  public class MyExpando : DynamicObject

private Dictionary < string, object > _members = new Dictionary < string, object > ();

/// When a new property is set, add the property name and value to the dictionary

public override bool TrySetMember(SetMemberBinder binder, object value)
if (!_members.ContainsKey(binder.Name))
_members.Add(binder.Name, value);
_members[binder.Name] = value;

return true;

/// When user accesses something, return the value if we have it

public override bool TryGetMember(GetMemberBinder binder, out object result)
if (_members.ContainsKey(binder.Name))
result = _members[binder.Name];
return true;
return base.TryGetMember(binder, out result);

/// If a property value is a delegate, invoke it

public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
if (_members.ContainsKey(binder.Name) && _members[binder.Name] is Delegate)
result = (_members[binder.Name] as Delegate).DynamicInvoke(args);
return true;
return base.TryInvokeMember(binder, args, out result);

/// Return all dynamic member names

public override IEnumerable&ltstring> GetDynamicMemberNames()
return _members.Keys;

When ever a property set operation happens, the runtime will invoke TrySetMember, and there, we are pushing the property name and value to a dictionary. Similarly, when ever a get operation happens (TryGetMember), we are simply returning the value object if available in the dictionary. Also, when a method call is made (TryInvokeMember), if the value type is a delegate, we just invoke the same by passing the arguments we received. Pretty simple, huh?

Well, that is it. Now, let us try the above scenario with our MyExpando object

          dynamic obj = new MyExpando();
obj.Value = 10;
var action = new Action((line) => Console.WriteLine(line));
obj.WriteNow = action;

Run the application, and you'll get the same output as above. Cool :)

Happy Coding

Dynamic Typing (Duck Typing) in C# 4.0

C# 4.0 introduced the dynamic keyword, to support dynamic typing. If you assign an object to a dynamic type variable (like dynamic myvar=new MyObj() ), all method calls, property invocations and operator invocations on myvar will be delayed till the run time, and the compiler won't perform any type checks for myvar at compile time. So, if you do something like myvar.SomethingInvalid(); it is valid at compile time, but invalid at runtime if the object you assigned to myvar doesn't have a SomethingInvalid() method.

The System.Dynamic namespace has various classes for supporting dynamic programming, mainly the DynamicObject class from which you can derive your own classes to do run time dispatching yourself.

A couple of points to note.

  1. The dynamic call will be slower for the first time, and your calls will be jited and cached if possible for subsequent calls. As a first step, the DLR checks the cache to see if the given action has already been bound wrt to the arguments. If not, the DLR checks to see if the receiver is an IDynamicObject, and if so, asks the receiver to bind the action. If the receiver is not an IDO, then DLR calls into the language binder (i.e, the C# runtime binder), and cache this.
  2. C#'s underlying type system has not changed in 4.0. As long as you are not using dynamic keyword, you are still statically typed (i.e, the types are known for the compiler at compile time).
  3. Error handling when you use dynamic features is a bit difficult and can't be very specific, as you don't know much about the foreign objects to which you dispatch the calls.
Recently, I published this article in Codeproject; Fun with Dynamic Objects and MEF in C# 4.0 - A dynamic File System Wrapper

This article demonstrates a couple of interesting techniques, including.
  • Creating a dynamic wrapper around the file system so that we can access Files and Directories as properties/members of a dynamic object
  • A way to attach custom Methods and operators to our dynamic wrapper class and dispatch them to a plug in sub system.

Think and act ‘Beyond The Obvious’

One of the finest qualities of a manager is his ability to 'Not to get emotionally dragged'. The ability of seeing things objectively will highly enhance the management quality in us.

Being in this stage, dealing with 100 different issues at the same time becomes so natural. You will never miss out on reading important mails, on mail reverts, and even attending an evening party while a crucial delivery is happening in parallel on the other end.

Keeping one or more focus in your career is extremely
important to attain this stage. You can decide the number of focus points depending on your multi tasking capability. But it is advised to start with minimum.

It can be things like;

  • Achieving you project/unit/company goal in terms of revenue, number of employs
  • Achieving client delivery excellence etc
  • Achieving your personal goals (But make sure your personal goals are aligned with company goals)
  • Achieving a high level of employee satisfaction in your team
Once you have this goal, you are all set to tackle many issues that you will come across on a day to day basis. Having set the background for the topic, let me come back to my topic - 'Think and act beyond the obvious'. Among the many of the issues that you may come across, I am interested in applying the above logic in ‘Team handling' and related issues'.

While handling the team all managers will come invariably deal with - appraisal sessions and related activities.

Going by the guidelines set by the organization without any deviation during appraisal sessions is one way of doing it. It doesn’t require much skill and can be done easily.

But being intelligent and applying logics along with the above will take it one step further and will really help the team perform in future.

At this point you should start 'Think and act beyond the obvious'. There are certain acts which falls in 'beyond the obvious' category - which I would categorize as 'Value adds' while managing. Which means, it doesnt necessarily fall in to the standard guidlines set by the organization.
To make it clear, please see the below chart.

The moment we add more dimensions to the obvious category tasks, the quality of thinking pattern in the team changes. This changes the dynamics of the team. And when team’s thinking pattern is focused and matured, it becomes collective consciousness.

Yes!.. This is the level at which a manager should operate.

It is your capability to make your team think beyond the call of their duty, that makes the difference, ultimately it will lead to a dynamic team.

As a Manager, you should know the depth of your teams capability. If you don’t know where you stand at the moment, you can’t take your ship to the next required port. This is a world that moves on theory of relativity.

The team is as good as the team's manager.