Category: Learning
“It’s not Personal” – IMA’s inaugural networking event

Well, this may not have been the official title of the event, it was definitely one of the key takeaways from our guest speaker, Jane Huxley.

We set up this night, with the aim to build on the events we have been having in Melbourne over the last 12 months, getting guest speakers to speak at our company meetings, to share some insights and hopefully drop some inspiration for our Consultants. The powers that be in IMA Sydney, decided to take this idea one step further. We invited along, not only IMA staff, but their partners, clients and people from our talent pool to join us in learning, with the added benefits of some magnificent canapes, drinks and stimulating conversation.

Jane Huxley, (as of writing this) the soon to be MD of Spotify, was our headline act. In short, if you are in the position to get Jane to speak at an event of yours or you can steal her for a 30 minutes coffee, take it, take it every day and twice on Tuesdays. Jane was amazing. For someone whose background includes roles like MD at Pandora (music streaming not jewellery), CEO and Publisher at Fairfax Digital, Head of Product at Vodaphone, and a Director at Microsoft, she was so relatable to everyone in the room and really impressed everyone. As mentioned about “it’s not personal” or “INP” was a takeaway we can all learn by, when those days are getting a little long, and the meetings a little too awkward or tough. Her stories on mentorship and disruption and her strength on mind to succeed had everyone at the edge of their seats.

It was a great night, even if I didn’t get to win the Haighs chocolates, I draw comfort from the fact that a person who scrubbed my name off one of my business cards and wrote her name at the back of it did win. No commission for this little Recruiter for that transaction… unless they are in the mail of course. I hope you see this Madeline Jack

Challenges in Agile Project Management
Gayathri Ramamoorthy

Gayathri is a proven Project Manager with experience spanning over a decade in the IT industry in all areas of the SDLC. A strong end to end technical and functional background has enabled Gayathri to perform multiple roles such as Delivery Lead, Project Manager, Solution designer and Technical Consultant over the span of her career.

In last few years, we have been hearing the word ‘Agile’ frequently in the project delivery workspace. Quite often, we had constructive debates and interesting discussions among colleagues on challenges in Agile projects. Common concerns were – lack of ownership from team, mixed signals from senior management and ineffective cost management. I would like to share my experience where we applied agile methodology to a project aiming to deliver the functionalities/features quicker for the business to use and the challenges we encountered.

The project was initiated to develop new reports for a business unit to measure their sales performance. The data required to build the report was sourced from a datawarehouse which hosted the consolidated transactional data from various source systems. The project scope was to develop reports and to implement the required business rules and data transformation. The project applied agile techniques to deliver the reports in an iterative deployment schedule. The features required in the reports were listed and prioritised by the business sponsor and the sprint period was 4 weeks. In Agile methodology, sprint is the time period within which a selected list of feature is completed and made ready for business use.

In an agile project environment where the team is set of highly skilled developers, a sponsor who was supporting the team to follow agile framework, a management team who applied the agile techniques appropriately, what could go wrong in such agile project? In spite of an optimistic agile environment, there were still challenges.

Design changes during the iterative sprints – Are you thinking of doing design, development and testing in an agile way? I would recommend to read ahead and validate if that approach would help your project to achieve the desired outcome on time.

The project started with minimal business requirements from the business and the list of features required were identified. The project included redesigning the underlying data model of an existing application and adding the new features identified to the application. The project did not have the detailed requirements at the start of the project and the design, data model, build and testing started simultaneously following agile approach. As we progressed through sprints, any design or data model changes, while developing the features down the line, eventually resulted in rework on the features completed in earlier sprints. The finished products were revisited every time there was a change in design which increased overall cost and caused delay in progressing with the remaining open activities.

From my experience in this agile project, it would be challenge to complete the sprints on time if design is evolving across sprints. If the project involves major redesign or new application development, it is worth investing initial few days in preparing high-level design with the available requirements. This would avoid rework on the features while we get into the development sprints. Development and testing goes well within a sprint timebox.

Team member sharing while sprint is in progress – The projects had a dedicated skilled team which was a key strength to get the development on time and of high quality. The project deployment was planned into multiple deployment phases so that the finished products can be released earlier. There were cross impacts due to other inflight project and the part of the development team was deviated to focus on sharing the knowledge of the project and its impact on other projects so as to enable first deploy release to go ahead as planned. As per Agile guidelines, the core sprint development team is expected not to be deviated from the locked down list of features. But in the real world, the knowledge of the skilled team is required to mitigate any risks related to that project. We had delays on the sprint that was in progress in order to accommodate risk mitigation activities. A dedicated and committed team is a key for a successful Agile project. The agile project manager should implement the two key techniques that the Scrum methodology emphasises strongly.

  1. The Scrum Master should ensure that the team is not impacted by any changes or other external influences that could potentially deviate the team from the current sprint. The Scrum master should ensure that the team remain focussed on the current sprint until the end of sprint
  2. Any changes in resource plan should be restricted while the sprint is in progress.

Requirements unclear even while sprint is in progress – Agile framework facilitates the business SMEs to change or finalise requirements while the feature is being developed. But in order for the development team to complete the development within the sprint time, the business should be clear on the requirements for the features in the current sprint to enable on time completion. Ambiguous requirements, while sprint is in progress, lead to delays in completing the feature within the sprint and may result in increased backlog.

The business subject matter experts have to have the requirements clear to enable the team to complete the project on time. Any requirement changes from the business SME impacting the sprint has to be considered as a new item in the backlog list. Requirement changes during the sprint has to be recorded and tracked to effectively manage the sprint timelines and overall project cost.

While Agile framework accepts less documentation, we need to understand the main objective of agile framework is quick delivery. Documents that enable quick delivery and better control on time and cost are still required in agile project management. As much as projects are unique, challenges within the projects are also unique. Lessons learnt from past experience always helps in the handling these challenges effectively in the future. Agile methodology also gives the opportunity to identify any challenges at the end of each sprint which will enable to apply corrective measures throughout the journey of the project. Go Agile, enjoy the continuous learning and eventually master the skill of Agile project management.

Learnings from an evil boss

Screen Shot 2016-03-22 at 12.34.58 PMWorking in the HR arena is tough! Especially in bad times. Who likes sitting across the desk from someone explaining to them that as of now your livelihood has been taken away. (I have only met person ((and catbert)) in my career who actually enjoyed it)

We are hearing lots of stories about redundancies at the moment, I was talking with one of my colleagues today about this and how we (the collective “we”) handle it. We must remember there is almost a whole generation in the workforce who have never seen a downturn. Sales people who have never seen an environment where budgets just weren’t to be found, HR people who have never had the “I’m sorry, there is just no job for you here anymore… through no fault of yours”, or candidates who have never had to find a job in a candidate rich market.. phew.

Thus the people delivering the bad news, may have never experienced the bad news before (or had to deliver it before) and may find it difficult to engender sufficient empathy to perform such a task adequately.

Poor handling of such events actually pushed me into this industry! Originally I wanted to be an HR professional. Why? because of the way a company handled my father and his redundancy. My father had worked for a company for 34 years (give or take), until in the early 90’s it was time to rationalise etc (during what one prime minister of Australia called the“Recession we had to have”) and his job was deemed redundant. How was it handled? Poorly from what I remember. Now what I remember may be a little inaccurate as it is seen through an emotional teenagers eyes. However, there was little council, little warning, little payout, little explanation, and less support. It was one of the rare times I saw my father in a very emotional state. The sole bread winner, having spent his entire working life at this establishment, only to get discarded like yesterday’s newspaper. His identity had been taken from him in my view.

My fear is that the marriage of these two points, could mean that, in these most difficult times, the handling of redundancies may not have improved.

In one of my first jobs, as a console operator at a petrol station, my boss decided to teach me a lesson. Why? I still don’t know, but the lesson was learned.

My boss at this time treated me like he was going to fire me. ALL day.. the entire 6 hour shift I had anyway. At the end of the day, he started the you’re fired conversation… I was really scared, stammering and stumbling over my words, really struggling through the conversation.

He then stopped, and grinned. “Have you ever been fired before?” he asked
“Nope” I responded nervously. “Well now you know what it feels like!” “so now before you decide to take this option with someone you know how it feels and how to respect the people you will be doing it too.” Powerful huh! This was almost 20 years ago. You know what, although harsh, and bordering on harassment, I’ve never forgotten it or the feeling.

For those of us who may have to sit in on discussions around redundancies, have the actual conversations, as well as those of us who now are charged with finding them new work, please keep a few things in mind.

Ensure you have thought of everything to prevent having to do this. Just because everyone else is, is not a good enough excuse.

Bring your empathy. Be human, and be aware that these business decisions will have real personal effects on the people hearing the news. It may not be personal to you, it will be for them… guaranteed!

Bring your respect, and give them dignity. Take your time in telling them, spell it out clearly and concisely (Don’t get in an argument though).

Expect to feel bad. That’s OK. The conversations are about them, not you. If people cry, allow them to. Give them space and time, silence is OK. Do not feel the need to fill a silent void with words.

Bring some options for them. Outplacement, agency names, something. Think about the people and what they may need before the discussion.

Be prepared for criticism and finger pointing, but again, there is no need to buy into arguments, the decision has been made.

And of course have everything organised, current and covered off BEFORE the meeting.. triple check it.

Bottom line… REMEMBER you are dealing with people (with lives, responsibilities, and dreams), not employees, not numbers, not inventory.

I read an article a little while ago which stated that

“More than 40 per cent of the Australian workforce has been made redundant at least once in their careers and for most (70 per cent) it was extremely stressful….”

The stress mentioned will be for a number of reasons, the loss of income, the loss of identity, the loss of self confidence due to the stigma attached to a redundancy.

Redundancies are not just a clear out of dead wood anymore. Good/Great people are being laid off too. IT IS A REALITY. We have a responsibility to ensure that people being made redundant know this, and as Employers, we need not to look at people who have been made redundant, actively challenge the idea that only the “Dead wood”, would be culled first. Hard business decisions are needing to be made everywhere.

OK, these are tough conversations to have, you have every right to feel uncomfortable and nervous about having them. If you are the person delivering the message…. Please remember these discussions aren’t about you, they are about the person you are talking to. Give them the respect and dignity they deserve by present for them and not just a messenger.

I am not a religious person, however the term “Do unto others…” rings true to me.



4 steps to failing your way to success

After one of those awkward lift conversations with a stranger, one of IMA’s Engagement Managers, Marty told me that I “experiment with everything”. In an attempt to improve my ad hoc conversation skills he’d seen me have a series of lift conversations, some awkward and some not, and noticed my endless fascination with giving things a go, seeing what works, changing something and trying again.

Ian, our owner and MD. Ian started IMA back in 2004 and has driven its growth ever since. Ian is always open to new ideas, and sometimes he even takes a few on!

Ian, our owner and MD. Ian started IMA back in 2004 and has driven its growth ever since. Ian is always open to new ideas, and sometimes he even takes a few on!

I’m applying scientific method to my life.

I’ve applied it to a huge range of things, including work, sport, holidays, friendships, dating, family relationships as well as awkward lift conversations. The results have been mixed, but I seem to always end up in a much better place than where I started.

I typically follow a pretty simple process.

What result did I want?

The first thing I do is that before every “measured event” is defining what success is. Funnily enough this is harder than you would expect. Why? Because you can’t expect a home run in every encounter.

In the consulting world (my business) it’s unrealistic to set a goal of winning work in a first meeting with a potential client. Do they have work? Are you even a fit for their business? Expecting a home run is focusing on things beyond your control. A better target is to find out if they have work, if you are suited to them, and if it all matches then building the relationship and scheduling a second meeting. Or in other endeavours, not everyone I meet in the lift is going to be my BFF (Best Friend Forever for those older folks), but perhaps I can make them smile and find out a little about them.

Setting realistic, progressive and measurable goals and doing it consistently is the key.

What result did I get?

Reflecting on your attempt is the next part. Once I’ve set a goal and tried to achieve it, I take a clear eyed, hard nosed, and honest assessment of the success or otherwise of my attempt.

Craig Horne (@craigthebold) used to ask me “What result did you want?” and then “What result did you get?”.

I love those two questions. They strip away excuses. You wanted result A you got result B. Nowhere to hide.

What do I need to do to get the result I want?

With the hard part done, the easiest is working out what you need to do to get a better result.

It’s easy because it’s OK not to know what to do.

In that case I usually just try something different that seems like it could work. And if I’ve run out of ideas I try something I think won’t work, but I always make sure I try something different if the result isn’t there.

The glue

What’s the glue that holds this process together? It’s you don’t be hard on yourself. Everyone is expected to be bad at first, second and third try in fact every time anyone learns a new skill.

I hate to fail, you might be that person too. Allowing myself to fail, or better yet, expecting to fail and being OK when it happens is the glue that holds this process together. It allows me to realistically assess what went wrong without making excuses. As the easiest way not to fail is not to try, expecting failure stops me avoiding failure by avoiding the situation, allowing me to jump back into the fray immediately and try again. And volume is often the best method of improving at anything (see my post on working harder not smarter).

So that’s how I am failing my way to success one awkward lift conversation at a time.



“That gut wrenching feeling” – decision making from the top.

I’ve come to appreciate feeling nauseous at work.

Ian, our owner and MD. Ian started IMA back in 2004 and has driven its growth ever since. Ian is always open to new ideas, and sometimes he even takes a few on!

Ian, our owner and MD. Ian started IMA back in 2004 and has driven its growth ever since. Ian is always open to new ideas, and sometimes he even takes a few on!

I’m talking about the kind of nausea that doesn’t come from being sick but that gut wrenching, internal conflict when you believe a course of action is the right one but it pushes new boundaries and makes you uncomfortable, unsettled and dreading the consequences.

I had that feeling when I decided to stop consulting and to work on growing the business. When I interviewed a candidate who was well outside our price range, only to realise that I had to redefine our business model because we couldn’t let him go. When your stars have performance issues and you need to have a confronting conversation.

It’s not comfortable but growth never is.

I was reading a post on the fog creek blog when I had this feeling. Dan Ostlund was describing how Fogcreek stopped paying their salespeople commission. It hurt to read it.

It hurt because I knew that commissions didn’t help sales. I’d seen Dan Pink’s TED talk on motivation.

It hurt because I knew that once you removed salary as a factor the people just got on and did the job.

It hurt because I’d seen it countless times.

The people who complained, “If you pay me I’ll do it”, never did.

I’d seen sales people who reaped the rewards of the good times but stopped selling to complain about their commission during the bad times.

It was way to risky to do though.

Every salesperson worth their salt wanted commission, you couldn’t possibly not do it.

Because, because, well … everybody did it.

Well not everyone, Fogcreek didn’t.

They’d seen the research and removed commission from their sales team.

And it hadn’t hurt them, their team collaborated more, the admin overhead was gone, the conflicting incentives were gone.

The move made sense for us as a company. Removing commission would mean that our sales team had no incentive to put the wrong people in the wrong roles. Our team had always looked after their clients but removing conflicting incentives encouraged them to be completely on their clients side, which I love. Without commission a failed engagement didn’t help their pay packet, but it damaged their relationship with the client and forced them to clean up the mess, which no one likes doing.

The end result was a closer and more trusting engagement with our clients. Our clients loved it too, the changes were subtle but they enjoyed having someone to talk to who wasn’t going to make a dollar if they took their people. I loved the response when I told them we didn’t pay commission anywhere in the company. The reaction was usually a combination of surprise, a little puzzlement and appreciation. It wasn’t expected, it was unusual, but they liked it.

During the time we made the change our consulting staff retention has improved, there are a lot of factors that go into this and the market is the biggest one, however we’ve noticed a general improvement in engagement and moral in our company, having a sales team that cares about the consultants, our clients and how we are delivering to our clients has a positive influence on that. Rewarding our sales team for putting consultants in roles they didn’t want to be in got in the way of staff retention.

When implementing the change I took the path of least resistance. This allowed me to dip my toe in the water and see how the change went. At first I did it with our Account Managers, the team that looks after existing clients. As our personnel changed, the new team members were all taken on without commission, both the internal and external hires. This was also the change had the greatest affect on our clients as they handled all the day to day interactions with them. It’s hard to measure but tensions in teamwork within our sales team appeared to go down. That may have been the change in personalities but removing an incentive that encouraged division certainly didn’t hurt.

We still had a few salespeople who were on commission. These were the ones that concentrated on finding new clients. One by one I sat them down and walked them through the changes. We proposed to increase their base and remove the commission. They’d end up with more in the bad times and less in the good times but would have no surprises. They’d know what they’d have in the bank every single week and could plan around it.

To my surprise they didn’t have a problem with it, there were some initial questions and a few discussions early on, however the predictability was reassuring and over the Christmas period where revenue and commissions are down, when our consultants are on holiday they’re not earning us money, it was particularly valued as there was no holiday season penalty.

Even our new hires didn’t balk at the system, but appreciated the consistency of income and the level of trust we’d placed in them to perform when hired.

The big concern about the change was how do you motivate the team without a financial incentive.

It’s strange but that is one problem that hasn’t changed.

Motivation of our team was a problem when we paid commission and it’s a problem now we don’t. I had expected expect commission to resolve the motivation problem, but really it doesn’t change it one iota and so you have to deal with in the same way as usual, through good management.

Paradoxically removing commissions has had a significant impact on my role. It has taken away my excuse that I didn’t have to get the team motivated because their commission should do it. Fittingly the responsibility is back on me to do my job properly, not to shirk the difficult conversations and take a more active and aware, but not necessarily overt, role in their performance.

Implementing the change went significantly smoother than I expect and it’s had a more widespread impact than I predicted, affecting our sales team, consultants and even our client engagement.

That sickly feeling of having to actually deliver something that was counter to established norms turned out to be unwarranted and removing commissions is one of the changes I’ve made to IMA that I’m most proud of.


Work harder not smarter
Ian, our owner and MD. Ian started IMA back in 2004 and has driven its growth ever since. Ian is always open to new ideas, and sometimes he even takes a few on!

Ian, our owner and MD. Ian started IMA back in 2004 and has driven its growth ever since. Ian is always open to new ideas, and sometimes he even takes a few on!

The mistake in the work smarter not harder adage was highlighted to me by my 9 year old son.

I had been moving his music practice from 15 minutes a day to 20 and he didn’t like it.

Mr 9 works best when he has control of his life and changing the amount of practice he did took his control away. My solution was, if he couldn’t control his practice, let him control mine. He got to decide how much practice I did with my recently acquired guitar.

I suspect you can see where this is heading.

The good news, the problem was solved, Mr 9 did his 20 minutes happily and set me 20 minutes a day.

A week and a half later he decided to flex his muscles.

I did 1 hour and 20 minutes of practice that day.

The following day it was 1 hour and 10 minutes.

Then 1 hour and 20 seconds. His reign of terror had begun.

After 4 days of practice he wasn’t reducing his demands, but something unexpected had happened. Because I was practicing so much my guitar playing was improving much faster than it had. I decided I liked it and, much to the surprise of my sons, voluntarily kept to his 1 hour a day regime.

I’ve seen the same thing work in sales.

People condemn mindless activity, but I’ve found once you work smart enough, often it’s better to just increase the volume of the core activities rather than spend time tinkering to get things just a little bit better.

Preparation can be procrastination.

The funny thing with the increased activity is if you are alert, think about what you’re doing and assess for improvements, the increased volume means increased opportunities to learn. So by working harder you end up working smarter as well.

I didn’t forget to thank my son.

The importance of Stakeholder engagement

 

Pablo Arias

Pablo is a seasoned professional who is focused on delivering high quality outcomes for his clients. His strength is his ability to quickly develop relationships with stakeholders at all levels to find a way through complex issues. Highly qualified with an MBA and over 14 years’ experience in consulting and project management, Pablo has helped his clients in numerous industries including Education, Health, Defence, Telecomms and Finance achieve their business and project objectives. When he is not immersed in solving his client’s most pressing challenges, Pablo enjoys spending time with his children and cooking a variety of delicious cakes and desserts which makes him valued team member for morning tea. He also doesn’t mind a long drive along the coast every now and again.

Recently, I completed two successful projects which involved delivering new technology to the Classroom – but were they really ‘successful’? The business case was approved, the budget and plan agreed with the sponsors, vendors and resources were engaged and there was enthusiasm from the project team about the innovation that would be delivered to students and staff as a result of this new technology.

As the project progressed through design, procurement and implementation, some key business decisions were required from key stakeholders. Fortnightly meetings were held with the steering committee to present project status, issues, risks and to gain input for the key business decisions. What quickly became evident to our project team was a gap in stakeholder engagement and management. What we really needed was a Change Manager – someone who could articulate the project requirements and business benefits and communicate these with the stakeholders to gain their buy-in.

Fortunately, the project was finally able to secure two additional resources to assist with these important change management activities but they were only engaged towards during the end of the delivery phase of the project. As a result, this meant the business deployment activities were delivered in a less effective manner. For example, although training was planned and organised, attendance and participation was poor due to a lack of awareness of the project and its purpose, objectives and benefits.

Similarly, finding willing participants for the trial period proved to be difficult and resulted in some classrooms with new technology that nobody used.

So back to my original question – would you consider these projects to be successful?

Ultimately – the answer has to be no. The expected business benefits of such technology could not be realised if no-one is using the technology.

So what are the lessons learnt from these project examples? Here are my key take-aways;

  1. Don’t underestimate the importance of change management requirements in any technology project. Secure a Change Manager and ensure they are part of the entire project journey.
  2. Stakeholder communication and engagement is absolutely critical to the success of a project. This requires regular communication with all stakeholder groups throughout the entire project duration in order to take them on the journey as well. They need to become the ‘owners’ of the business benefits.
  3. Identify some willing project ‘champions’ from the business – these are stakeholders who act as ambassadors for the projects, who are willing to trial the technology and greatly assist in raising awareness amongst their peers.
  4. Regularly publish and promote project communications to provide broader stakeholder groups with key messages about the project, its goals and benefits – another key method to raise awareness.
  5. Finally, it is critical to understand the ‘impact’ of technology on current business processes and workflows. Develop strategies to assist business users to embrace the technology including training, help-guides and on-site support.

So can a Project Manager also undertake the role of Change Manager in such projects? Given the right experience and size of the project, I don’t see why not.

I would definitely be keen to hear from other Project Managers and Change Managers who have encountered similar experiences and hear how you managed stakeholder engagement.



A BUSINESS ANALYST’S VIEW ON BEING A BA
Kathy has only recently joined the team here at IMA.  Kathy comes to us as a very experienced Business Analyst, mostly specialising in the Superannuation field.  However, within her 27 years in this industry she has travelled across many area’s including Operations, Investments, Accounting and IT. Kathy experiences within this industry have led her to land in the Business Analyst space, where she is passionate about streamlining and improving business processes. Kathy is a great communicator with strong presentation skills.  These attributes assist to make Kathy a great trainer able to deliver training material clearly. When Kathy isn’t working, she loves to travel with her young family.  Trips overseas and spending time with her family are things she looks forward to.  But when at home, you will find Kath in her kitchen cooking up a storm, another one of her passions

Kathy has only recently joined the team here at IMA. Kathy comes to us as a very experienced Business Analyst, mostly specialising in the Superannuation field. However, within her 27 years in this industry she has travelled across many area’s including Operations, Investments, Accounting and IT.
Kathy experiences within this industry have led her to land in the Business Analyst space, where she is passionate about streamlining and improving business processes.
Kathy is a great communicator with strong presentation skills. These attributes assist to make Kathy a great trainer able to deliver training material clearly.
When Kathy isn’t working, she loves to travel with her young family. Trips overseas and spending time with her family are things she looks forward to. But when at home, you will find Kath in her kitchen cooking up a storm, another one of her passions

The wonderful world of a Business Analyst or a “BA”– sounds cool, huh???

Well it is a pretty cool gig!

For example, when you catch up with old school friends, who you have not seen in a while, and they say “So what do you do for a living these days?” and you very cool and very casually say “Oh I’m a Business Analyst”. They will look impressed right? That’s because we are an impressive bunch!

So What Is It You REALLY Do?

Well that’s generally the next question, because even though our title implies we “analyse business”, it doesn’t give too much away.

Do we keep an eye on the stock exchange and international market movements? No that would be an Investment Analyst

Do we keep an eye on interest rates and its impact on the property market and trends? No that would be a Property Analyst

Do we analyse consumer spending to see where and when consumers are spending their hard earned dollars?? No that would probably be a Retail Analyst

So where does that leave us??? Well a business analyst would work in any and all of the above fields, just not performing those particular roles. As a business analyst, we tend to align ourselves with the business and more closely the operations of the business.

Our role is to understand an operational requirement (the business wants to…) and convert this into reality – we call it a “solution”!

How do we do this?? Well we have the skills required to

  • Understand “business” speak, (yes we speak business!) à know what it is that the business really needs (as opposed to what they may tell you they want)
  • Translate this “business” speak into “technical” speak so a software developer can understand what they need to achieve, if any new development is required as part of the solution
  • Before we head off into full development of the solution, we confirm back to the business that we have understood their requirements (what they want).
  • This can be done via a number of different ways, depending on what the business prefers. But generally a “Business Requirement Document” is written which will explain the total solution, and any peripherals such as reporting or outputs and screen designs
  • Once the business reviews these “requirements” and agree “yes this is what we want” then we are on a winner and we can move forward with the solution

But that is NOT where our story ends – no sir!

Through the development phase, any question or issues that may arise (hopefully these will be few and far between), the business analyst will be the first port of call. They will need to make decisions as to who or how these issues can be resolved.

Once any required development has been completed, it has to be tested (we call it user testing).

Again depending on the organisation’s set up, the business analyst may have written a test plan to test that the solution works as per the requirement document. They may even have to execute the test plan. Otherwise the business analyst will liaise with the test team to write a test plan for the test team to execute.

But wait there is STILL more! Now that the business analyst has designed a solution, tested the solution works, it now time to roll it out and train the masses (the end users).

Training people is an important part of a business analyst’s role. There is no point in developing something, if no one knows how to use it.

In all of the above reading, there is one KEY aspect, which you may have noted. It is the business analyst’s ability to COMMUNICATE.

We COMMUNICATE with the business to help them ACHIVE their goals

We COMMUNICATE with developers and other key stakeholders to help the business ACHIVE their goals

We COMMUNICATE with the end users so they know how to use the solution

See it’s all about COMMUNICATION, and a good business analyst has great communication skills.

So What Have You Done to Become a Business Analyst?

Another popular question and there are a number of ways a person can become a Business Analyst

Some of us can rise through the ranks from Business Operations to Subject Matter Expert (SME) to business analysts

Others may have gone down the path of completing any number of “business analyst” bases courses, studying delivery methodologies such as “Agile” or “Waterfall” or “SCRUM” or others. They learn the art of listening, understanding and communicating.

Sometimes a good business analyst is discovered in the work place when given the opportunity to work on a project. They shine with their ability to simplify a process, or understand a complex issue and help design a solid solution.

So Why Would You Be a BA?

Well in my view being a BA gives you a wide range of activities, which keeps our job diverse and interesting.

Unlike many others, we have touch points in business (incorporating business operations and administration), IT, Accounting, Project Management, Training, Testing. We don’t necessarily “specialise” in any ONE field, but we have good broad knowledge of many fields. This knowledge allows us to pull together other the specialists fields to achieve one common goal (yes this is where the communications come into play again).

Having this diversity means there is never a dull moment. However the best thing is the sense of achievement when you deliver a solution and your client says “Wow! That’s pretty cool!”


Why Buzzwords lose their value
Ally Lancaster

Working in the recruitment department, Ally is one of our most recent additions to the IMA family. She is a self-confessed perfectionist that has recently formed an addiction to LinkedIn. Ally is eager to learn and is always ready to take on new challenges in and out of the office.

Let me state this right up front.  I am not against buzzwords.

Often they are the most accurate and efficient way of communicating a message. As a leader you need the ability to break things down, simplify and be to the point. Buzzwords, when used correctly do exactly that. They understand that your time is important, and seek to inform and educate you in a precise and powerful manner. Yet as a society we have waged a war against buzzwords. We roll our eyes at ‘strategy’, tune out at ‘synergy’ and stop reading at ‘leadership‘… Still here? The problem does not lie within the words themselves but in the way that we use and receive them.

Buzzwords lose their value when they are used in the wrong context. Knowing your audience is essential for good communication. There is no point throwing in the word of the day if it’s not the right type of language for with whom you’re speaking. Understand the meaning of your chosen word and how it will resonate with your audience.  Choose your words appropriately.

Buzzwords lose their value when they are used without substance. Too often, words are thrown into documents or presentations without good reason. It’s a form of exaggeration, which has unfortunately become commonplace. Exaggeration is a practice that actually devalues our language and makes people less likely to listen to us. If buzzwords are used without substance behind them then there is little point in using them at all. It is essential to make sure your communication is purposeful. Choose your words wisely.

When used correctly, buzzwords effectively communicate meaningful messages but we have become so accustomed to the inappropriate use of them, that we immediately disregard those who use them. I think its time to give buzzwords another chance.

So, for the buzzword user

Ensure you know your audience and pick your words accordingly. Have purpose behind the use of your buzzwords and a sound understanding of their meanings.

And for the buzzword receiver

Before immediately disregarding anyone who uses them, assess whether that word was used in the correct context, and ask yourself if it added value and clarity to their message. You can then thank them for their effective and time saving communication!

Why Buzz Words Aren't So Bad

 



Project Documentation – Striking a balance
Aneesh web pic for blog

Aneesh started his career in 2007 as a Business Analyst and joined IMA in 2013. He brings tremendous energy, focus and initiative to his job as a Business Analyst. When not solving client’s problems, he spends his time driving around the suburbs occasionally taking out his camera for a snap or two .

Documentation has always been a part of formal project management practices. There are many layers of documentation that get created. The three types that are normally done are:

(a) what is to be built
(b) how is it to be built and
(c) how the project is to be managed.

But often, documentation ends up being a task that is to be completed before ‘actual’ project execution begins.

Many IT projects involve multiple stakeholders and draw upon diverse skill sets of many project team members. The team may include project managers, technical and business architects, business analysts, developers, testers and change managers. The project is often governed by committees whose members may be involved in many projects.

Team Members

The members of the team then interact as required with the client who itself might have a hierarchical set up for approvals for requirements, testing and deployment. The role of each member of the project team and the client varies at each stage of the development life cycle and the stakeholders must make necessary adjustments as their roles changes.

Project Management Office

PMOs usually ensure that projects are well managed by implementing project management standards and procedures and often mandate various project management documentation in the belief that all well managed projects need them. The detailed documentation of the schedule of activities and expected outcomes/deliverables with timelines provide immense value from a management perspective. Mandated documents and their structures enable anyone familiar with them to quickly find information relevant to them on any of their projects. It provides an easy frame of reference for any project team member to assess his own role in light of a plan and prepare for the road ahead. Such documentation is especially relevant in projects requiring services of specialised consultants who are called upon in the project at appropriate stages and their roles could be limited to that particular stage. The project and programme management is also clear on the artefacts that are to be expected at any point in the project life cycle which results in efficient deployment and utilisation of project resources.

Other

However, there are cases where projects with comparatively smaller budgets generate these documents for the main reason of complying with the PMO and in the process spending scarce time and budget in documentation. There have been instances where it consumes a significant percent of the project duration and cost. It may also delay the project implementation in some cases.

So the moot point here is what level of project related documentation is optimal. The most logical answer seems to be “It depends”. The value of such documentation needs to outweigh its cost.

Agile?

At this point I am sure that many of you will think of Agile methodology as a possible alternative because of the preference given to deliverables over documentation. However not all business domains and industries have adopted agile as a preferred model and agile does not suit many projects and businesses.

Consider Parameters

Various parameters of a project like complexity of implementation, budget, duration, headcount etc. could be considered as inputs to derive a subset of the exhaustive list of project related artefacts. This sounds sensible as there seems to be no point in developing a whole gamut of project management documents to develop a website with just a handful of pages whereas it might make perfect sense to have all of the artefacts in a project aimed at developing an online student enrolment system for a big university.

In case of significant overlap of information in multiple documents it would be a good measure to amalgamate one or more of the documents into a single document. If there are various small projects which are executed under an umbrella programme, it might be possible to have documentation at the programme level. This will reduce the number of documents considerably. Projects in an organization could be categorized based on some of the parameters mentioned above and the artefact requirements could be defined for these categories.

To conclude, it is important to strike a balance on the level of documentation is required. For each project, what is appropriate might be different. Each document that is prepared must have a clear answer to the question ‘what is the value it adds’. This paper is only a flagging of the issue and suggesting some directions for change in broad brush strokes. Greater analysis of project management practices and methodologies is required in this area.