Monthly Archives: February 2014

EA for project management?

I was prompted to write this post as I saw on the Sparx forum a suggestion for enhanced Gantt chart features and in that suggestion it asks for attributes such as costs and hours of various kinds – i.e. real project management attributes.

Interestingly sometime ago, following discussions with a friend who is a project manager, I wrote a small Add-In for EA to integrate with MS Project.  Needless to say, what I saw as the requirement wasn’t exactly what they had in mind.  Skipping a lot of the ensuing discussion it became clear that a real project manager was unlikely to be interested in using EA, instead they wanted to inspect and extract information from EA into their world. Outcome – I wrote an Add-In for MS Project that interacted with EA. So with both Add-Ins each type of user could work within the familiar context of their normal tool and get the information they sought from the other world.

In the last few weeks I’ve written another EA Add-In for a project management system – this time Team Pulse from Telerik.  Once again to capture useful information into a tool that meets the users needs.

In a previous post I looked at improving productivity with EA and at the time it was clear to me that no single tool could do all the tasks I wanted and the need for the Add-Ins I’ve mentioned above just adds further supports for this argument.

Since my improving productivity post I spend some time exploring EA’s workflow. Yet again a potential area to organise and manage stuff.  Before I started my understanding and experience of workflow systems were of tools that help in the management and movement of tasks through notifications, prioritisation, checking and automatic escalation as needed. But what I discovered in EA is very much a user-centric model where a person can run a script to check the status of tasks and act on them as they wish.  Not what I expected, but on looking further into workflow models this is an accepted model.  I see it can be really useful in assigning tasks, and getting status information and ideal for small teams managing their day to day work.  Take a look at the Sparx workflow scripting example which illustrates this model – but I see it  very much as a low-level detail level tool, requiring the users to set up appropriate scripts – so no out-of-the box solution – and run them.  Perhaps EA could have some scheduling – ideal for a little Add-In a script scheduling tool – anybody else want it?

So back to project management.  In the early 1980’s I was exposed to some project management training with all the formulas and metrics for estimating the work involved with developing software systems – which I promptly forgot at the time it really didn’t help us get the work done.   However, I’ve always intrigued by project management, not least as it fits in with my approach of keeping things in order and well structured .

My experiences of project managers has been varied, and whilst trying to keep clear of project managers for much of my working life, I was heavily encouraged to go through project management training by one of my managers.  The aim was to give me some insight into the challenges they face and I can say it was a bit strange spending a week as the only developer in a room of aspiring project managers!

 

I remain intrigued about the whole process but my view is that most plans are really guesses and, if they were accepted with that mindset it would be fine, however a problem is that management often view plans as cast in concrete statement.  If you put down the real estimate the project possibly wouldn’t even get off the ground.  But of course these figures wouldn’t be politically acceptable so the plan is re-worked and thereafter developers etc are set up to fail before they even start….

As a potentially interesting aside, I recently attended an interesting talk on Critical Chain Project Management which promises a completely different approach to management and especially the way that estimates are created, used and managed – perhaps there are some nuggets from that methodology that could be the link between analysts, designers, developers and the project managers.

So the idea of bringing stuff into EA and making it a project management tool is interesting. Would having estimates, costs, budgets etc within EA be useful?  Who would use them?  Dare I say, would the figures even be viewed and accepted.

At present,  the method I’ve used for managing tasks within EA is to use the Task element (you really need a first class element if you want to interact outside of EA ) together with suitable tagged values that hold the information.  Pretty easy stuff, and you could always add a profile/MDG to ensure that they are added correctly and with defined values to minimise user error.  Within these task elements linked to use case, issues, changes, requirements, or in fact any element you chose, possibly with a stereotyped connector, it is possible for a those interested in the “project management” attributes to get visibility. Perhaps even having a few scripts to present the reports they need.

The one big issue I have with EA is that it uses several different task items (element tasks, task elements and project tasks) and they are not related – so the tasks that are used to produce the Gantt chart is not the task that an analyst may use – why??? A real inconsistency. Perhaps the suggestion on the forum should include rationalising EA tasks to a single task element, so that all the features within EA that use them work together.  Then the use of task element tagged values, which are readily accessible could be used by both the EA user directly and the PM using MS Project or other linked project management tools.

Whatever happens in the future, I’m looking forward to seeing how my Team Pulse Add-In works with EA.  Further, as an agile tool, and the need to closer cooperation between the various parties, I imagine that the barriers between the two tools should be lower.  Although I also suspect that moving from two to one tool is still not an option.

Adrian

Advertisements

Why would you want to write an EA Add-In?

I was thinking about the point I made in my previous post that Add-Ins may not be the right solution and, depending on what you are doing there may be some better options.  However, you may be curious and just want to have a go – a bit like me.  So in the spirit of exploration you follow some instructions for writing a simple EA Add-In, and hopefully get it working OK.

However, apart from trivial examples, writing an Add-In is not a small undertaking. So just before you dive into spending your time learning more about the techniques of writing Add-Ins, assuming that they will be the solution, I think it’s a good idea to reflect on why you think you need an Add-In, and in assess whether it make sense in your case.

If you are looking at writing an Add-In I would suggest that you probably fall into one of the following categories or something very similar:

  • You are an EA user and frustrated that the little bit of functionality you want is not provided
  • You are an EA user who needs EA to interact with other tools on a regular basis, for example to transfer data between them either to make your life easier or to enable you to use EA for a specific project or in a specific environment
  • You are a product developer and see that there is an opportunity to enhance EA to provide functionality that isn’t provided or is only available in a way that you don’t like, and think others would benefit from a different solution i.e. your solution
  • You are a product developer and you need to enhance EA to work with your other products to improve your customers experience

If I look at these requirements and focus on what you may want:

  • To integrate with other tools – e.g. to transfer information on a frequent basis
  • To harvest content from existing sources and want a customised solution
  • To customise the outputs from EA that cannot be done with the exist reporting tools or via a route that meets your reporting requirements/processes
  • The flexibility that you cannot get through other solutions e.g. scripting or existing Add-Ins
  • To provide interfaces to EA in a way that is not currently available – for example, you may wish to provide access to a limited set of data or need to perform integrity checks on data entry

So using these lists of requirements I’ll share some of my thoughts gained from my experience as an EA user, manager of EA Users, and EA Add-In developer; a bit of a check list. 

Although I have broken them down into different topics, many of these points are not independent, so need to be considered together, and probably with several iterations, before a decision is made. Needless to say the larger number of people involved or influencing your decision, the more challenging it will be. So here they are, with the caveat that I know I haven’t thought of everything – this is just the starter list, and I am sure that every situation will have its unique issues:

Are you sure that EA doesn’t already provide the solution? 

You may be surprised with this question, but the point I am making is that Sparx Systems have been doing a great job of adding lots of functionality and sometimes knowledge of this functionality is hidden.   I’m still discovering – it’s frustrating to find a new feature after having spent time sorting out a workaround so:

  • Before you go off and develop your own solution it may be worth checking the latest documentation or contacting Sparx support with your specific problems, as there may already be a solution
  • Raise a question on the support forum to see if anybody else is aware of a suitable solution
  • May also be worth checking if there are existing 3rd party Add-Ins

Of course, it may be that any solution you find does not meet your specific requirements but always worth a quick check.

Will one of the other automation solutions work?

If a suitable Add-In doesn’t exist you should consider if you need an Add-In.  Do you need to respond to EA events – if not then would some of the scripting capabilities within EA work,  or would the use of a scripting language such as VBA within the application you may be working with provide an adequate and possibly quicker solution to meet you immediate need?

One of the first tasks I had with EA such a long time ago was to provide capability with Excel to interact with EA.  This was all done with VBA .  Needless to say I think eaXL is a better solution but it can be done.

What support do you have for your proposed solution?

Depending on your situation, it may be that it’s your decision, but as soon as others are involved, either for approvals to proceed or perhaps more importantly as the potential users of your solution, then you need to consider:

  • Do you have established EA users who have a positive attitude towards EA?  Have you got them on side? or if not then you may be adding fuel to the fire! 
  • They may not like a solution being imposed upon them. Your solution may mean that they have to change the way they work – would they be happy with this? They may say they are, but how can you confirm that this really is the case?
  • And are you clear you have identified their specific needs? How can they or should they be involved to ensure that they take some ownership of producing the solution.

What functionality do you really really need?

You may have a vision for an elegant solution in mind but it may not what is needed to solve your current problem, in fact over specification make mean that it is a non-runner.

  • Can you produce a list of must haves vs nice-to-haves?
  • Can you further prioritise the requirements?
  • What is the impact of not getting all of your “must haves”? i.e. how “must have” are they really  – is it you or the problem specifying them
  • Is there a clear (and dare I say costed justification for each requirement) – really useful if others are pushing for requirements that you think are not needed!

Who will be the users of your Add-In?

The approach and choice of solution can vary significantly depending on whether this is a one-off need for a single user or for a wide range of users in different roles.

  • For a one-off use for a single user an Add-In may not be suitable or justified – either in time or just excessive – unless it can be a quick and easy “bodge” to an existing Add-In.
  • For the multi-role, multi-user solution the Add-In approach may prove useful in that the interface can, since it is under your control, be tailored to provide the level of guidance and protection you need.

When do you need the solution?

If you need it instantly you better re-calibrate and assess what would be a realistic expectation for the availability of an Add-In that you haven’t specified or started writing and then review the suitability of the proposed solution. If you really need it now what other options do you have:

Is there an existing Add-In or combination of products that could provide the solution, it may not be as elegant, but probably available much sooner. You may be in an environment where the long term solution would be an Add-In but you can provide a shorter term solution another way.

Although having written quite a few Add-Ins and could produce a simple Add-In within a few days or weeks depending on the functionality, integration etc, it really takes much longer to deliver a production quality product. So be careful about the quick fix – it may work but does it really do all you need.

Who is going to develop the Add-In?

If you are reading this it may be that you are a first time developer looking to produce the Add-In – Good on you, however whoever is doing the development it is worth checking their skills and experience.

  • Do they have the experience of developing the Add-In
  • Do they have experience of any other elements that are involved with the proposed Add-In whether this be other applications or services – in my experience this can be a bit of a learning curve (great fun but can take time)
  • If other tools / products are involved have you done an assessment of their suitability for the task that you expect them to perform.  For example the ability to programmatically interface with them e.g. are they are COM server, etc? and if you don’t know how will you find out? What experience do the developers have of these other tools?

Who is going to support and maintain the solution?

It’s all well and good producing an Add-In, but how long will the Add-In be needed and who will be looking after the Add-In. Maintenance is often the highest cost element for any product.

  • Who is going to provide the support? – by which I mean both help users of the Add-In – this can be a very time demanding activity and may not be costed in the project and perform any maintenance tasks that come with the Add-In
  • What support levels are required?
  • Is the Add-In going into daily use?
  • To how many people?
  • Where are their locations?
  • Who is going to do the bug fixes?
  • Who and how are updates to be managed?

How are you going to market your Add-In?

I know this may appear off the point but I just want to say to those who are considering develop Add-Ins as a commercial product you need to think hard and reflect on why you are developing and bringing a product to market. I’ve done it in both small and large organisations. Like me you probably believe that EA is a wonderfully useful tool and if only there was an Add-In to do *%$£*! then it would be so much more useful and everybody would buy the product; they wont!

It can be hard, and if it’s your money then be very careful – get help if you can at least to review your proposal.

  • Have you really identified a need in the market? Creating a need is an expensive and time-consuming business.
  • Have you a business plan? if not….do you know what one is? you need a plan (although in reality it should be name a business guess).
  • What level of confidence do you have in your figures?
  • What is the source of information – I know many figures will be guesses but it is hopefully backed up by some real and reliable research
  • Have you performed what-if cases e.g. reduced sales by 3, increased development/lead times by 3 – does it all still make sense
  • What are your expectations?
  • Can you fund the development?
  • Have you done a detail risk/impact analysis?

Plus a myriad of other points – I’ve created many products and had several start-up businesses in over my career – and not one of them was easy.

Convinced you want to carry on?

You got my starter list to consider if you are thinking about before starting to develop an Add-In.  It may be a no-brainer, you need one and your company will fund it, so you can just get on with it. If not, then perhaps there a few more points to consider.

Whatever the decision I trust that you have a really well thought out and detailed specification before starting.  I tend to start with an EA model as should any good BA – and then start the design … stuff for another day.

I do hope that these thoughts are useful and help you. And if you do have decide to develop an Add-In do have fun writing it.

Adrian

What EA Add-Ins do you use or need?

As you have probably gathered, if you’ve read any of my blog, I spend a lot of my “day job” writing EA Add-Ins.  It’s one of the great advantages of EA, and along with the general mechanisms to access the core EA object model, and some of the key reasons I selected EA so long ago. It wasn’t that I could enjoy spending my time writing Add-Ins (that came much later) but more that there was a mechanism to interact with or expand its functionality in the way that I may need.  

In fact, by removing a dependency between the features that Sparx may add to EA, and the specific needs of the users, means that functionality can be added as required, and in a timely manner. Furthermore, this functionality can be added by those who may have more insight into the need and/or other tools with which any integration may be required.

Writing an Add-In may not be for all – and I would argue that it may not be the best solution – (I’ll write my thoughts on this one day) – however, it can be entertaining.

Personally I make use of the following Add-Ins on a regular basis:

  • eaDocX – I wrote the Excel part and for me it is one of the most useful tools for getting stuff into and out of EA, especially when developing new models and using information from many different sources.
  • HoTools, written by Helmut Ortmann, which helps make my lines pretty (available from download off the Sparx community site) – so much easier than using the diagram tools!
  • Plus the tools I’m developing / testing such as eaForms plus some other project management tools.

If you take a look at the list of Add-Ins list on the Sparx site (Sparx 3rd Party List),  – many of them are very specific to a domain and very much in line with my expectation that the experts of the associated product have authored them.  If you then do a Google search you’ll find some additional Add-Ins, once again many provide integration with another tool, whilst others provide some enhanced functionality.

What interests me is what Add-Ins really people use? I know users of my own Add-Ins, but in terms of the broader EA community is there widespread use of Add-Ins?  What Add-ins are used?

I know the ones I use regularly are those that provide general functionality and this seems to intuitive.  Although I found it interesting that I had very little interest in an EA Add-In I wrote for MS-Project (I also write an Add-In for MS-Project which would work in reverse); I just put that down to the fact that there were very few project managers using EA – which wouldn’t surprise me. So it may not general purpose tools and need for an Add-In may not be the general rule.

If ignoring the very specific tools integration products, are there any other “general” tools for which an Add-In is required and doesn’t exist?  What do users want and why? It’s not obvious to me but would welcome any thoughts.

So with that final question I’ll go and look at one of my current projects – another Add-In!

Adrian

BTW: You may have noticed I’ve added information on some of my current Add-In developments in the sidebar – just a flavour of what we do at EXploringEA.