My day-to-day work as a Business Analyst
Today our guest-author is Peter Lefterov - a business analyst at Bulgarian Telecommunication Company.
I notice when I talk about Business Analysis people often have a very fuzzy idea of what I’m talking about. And the deeper I go into defining the profession from a general perspective, the fuzzier it gets.
That’s why I decided to write down the things I personally do on a day-to-day basis, and I hope this will help build a better picture for the uninitiated. Other BAs might do different things, but usually there a level of similarity, otherwise there would not be a name for the profession.
1. Documentation – Most known and usually most tedious BA activity. The problem I’m trying to avoid with this is to have 5 team members and 3 major stakeholders and amongst them 15 different ideas what we are actually doing. The Business Requirements Specification is a tool for avoiding this, but not the only one and often falls short of achieving the objective.
2. Process Analysis – I don’t do enterprise analysis, at least not on my current position. What I do is more focused – when we change the systems people will change their work process. What I’m trying to describe is how things are done now (the AS-IS point of view) and how the work will be done after the change (the TO-BE process). The purpose here is to demonstrate to the team what the changes we are making will actually achieve. It also visualizes in front of stakeholders in detail what business result they have requested.
Filed Under Business Analysis, Guest Authors | 2 Comments
Top-down Planning - Good or Bad?
I read recently an article in PM Hut blog by Keith Mathis where he categorizes top-down planning approach as a project management mistake. I didn’t agree with the author and I will try to put my arguments here hoping to start a discussion.
First point of the author is that top-down planning is old style. He says:
Top-down planning makes the assumption that upper management has the best processes and ideas to run a project smoothly.
I think the author confuses planning with management. Top-down planning means dividing the project’s work into several big parts, then each parts is divided into smaller parts and so on until we reach small enough tasks that we can estimate and assign to somebody. Nobody said that it has to be done by the upper management although I believe that the first steps in dividing the work should be made by the project manager not because she has the best ideas but because she has the best view of “the big picture”.
Filed Under Project Management | 5 Comments
CIO Top 100 Companies For 2008
The CIO magazine announced the top 100 companies for 2008 that are creating new business value by innovating with technology. The chart in the magazine’s site shows the winners and their winning projects. For each company you can see their industry or revenue, their project type and the main technology, the primary business function and its impact. You can click on the company name to get more details or you can click on the tabs to sort the data.
It is intersting to notice that giants like IBM and HP are always “subscribed” to charts like this while Microsoft, for example, is missing. What impresses me most is that a great part of the companies Jim Collins analyzes in his books Built to Last
Take a look at this chart and I will be glad if you share your comments about the companies enlisted.
If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email.
Filed Under News | Leave a Comment
Loyalty
A great quote on loyalty by Stephen Covey. I found it in the Slacker Manager blog and I want to share it with you:
You can buy a person’s hands, but you can’t buy his heart. His heart is where his enthusiasm, his loyalty is.
- Stephen Covey
Of course, it is the most difficult thing to do - to win someone’s heart - but I believe that it is the best way to win their loyalty and devotion.
If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email.
What is the project goal?
The PMI definition of a project says that it is “a temporary endeavor undertaken to create a unique product or service” but it doesn’t say why we need to create that product or service. This definition is so often quoted and it makes the impression that the question “Why?” is not so important. Well, I believe it is.
Many people explain that the answer to the question “Why do we do this project?” is called a project’s goal and it is very important for the project manager to stick to it and never deviate. While I agree completely that everything we do in our professional life should be done for a reason and in project management it means that we should know why we are doing that project and never forget it, I disagree with the term “project goal” because it is misleading.
There is no project goal because only living creatures have goals. A stone doesn’t have a goal so doesn’t a project. There are two parties involved in a project usually - the customer and the implementor (the project team). They have goals and their interest is written down in some form of contract.
The customer’s goal is usually a business goal - to solve some business problem, to increase the income, to decrease the expenses, to maximize profit, or to improve the company image. They believe that this goal can be achieved by creating the product or the service as a result of that project. Many people say that the project goal is the customer’s goal. But there are some questions here:
- What if the customer assumes wrongly that the project will achieve their goal? What if you know that what the customer requests are plain stupid? (In the case of software it is usually because they give direct instructions how the product should look like without having any idea how a to develop software) What should you do if you know that in the end they are going to realize that they have spent their money for nothing?
- What is the implementor’s goal? Is it the same as the customer’s? Isn’t it just to take the customer’s money? At least that is what we do - make software for money. Why should we care about the customer’s goals?
What do you think? I am going to share my opinion on these questions too in the future posts.
If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email
How would you reward your employees - cash or gift?
This is an interesting question I’ve been thinking for a long time on but today I found a post in the Predictably Irrational blog (thanks to Bas de Baar!) and I decided to put my own thoughts on a page. I already wrote about the motivation here but this time I think it’s more a matter of culture (individual and national) than just a management problem so I published my thoughts in a post on my personal blog Stop and Think! Read it there and then share your comments!
If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email
How To Motivate Your Team?
Bas de Baar asked this question in his blog Project Shrink and asked his readers to suggest their opinions. I have always thought that having motivated people is the key to the project success but I really haven’t got “a recipe” how to motivate a software team. In fact, I know a lot of things that you can do to undermine your team’s motivation and trust, a lot of classic mistakes you can do but I didn’t have a ready answer to that question so I had to think a little deeper but I finally came up with an answer.
Let you team members be creative!
Don’t “Drill Down” Into Technical Issues
I am going to create new series in my blog called Advices to the novice project managers and I think it would be very helpful especially for software developers stepping into the project management field.
There are many occasions when a project manager is tempted to take on some development tasks especially if she is an experienced developer or when the project management activities don’t require full-time commitment. Things go worse when a technical issue arises and apparently there is no team member who can solve it. The project manager’s heart cannot restrain from plunging straight into the problem; she buries herself into that technical challenge and after that nothing can draw her attention back until a solution has been found.
This a very dangerous temptation and many former developers give in to it. The problem is that while you think about that specific technical problem you forget about all the other obligations you have as a project manager. As the old proverb says, you cannot see the forest from the trees. But your new position requires that you never lose sight of the forest.
Filed Under The Role of the Project Manager | 3 Comments
Techniques for Gathering Requirements
I found recently an article called 10 techniques for gathering requirements. While Tom Mochal is a very competent expert and I admire his opinion a lot, some of the techniques he describes look too trivial - one-on-one interview, group interview, facilitated session - they are pretty much obvious.
More interesting to me were some techniques which I find very efficient but seemingly more rarely used. So I decided to take a closer look on them and to analyze them in more details.
- Following people around (Observation). It happens very often a customer to come to us with their vision about how the new product should look like and what it should do without being able to explain what exactly is the business process running in their company or how it is going to change with the deployment of the new software solution. One of the most effective approaches to study the customer’s business process and the habits and the technical skills of the future end users is just to stay there and observe their daily activities. Observation gives us the ability to see some flaws in their work, some too complex or unnecessary activities that could be eliminated or to get some ideas to improve the process and thus to increase the customer’s profit from implementing the new software solution. It is much better if our business analysts have the ability to the actual work the users do to get a hands-on feel for the real situation.
Unfortunately, we are often pressed by tight deadlines especially in the analysis phase (which is a big mistake!) and we rarely use this technique for gathering information.
Sometimes, the customer doesn’t allow us to meet their employees using security arguments. In those cases we should strongly emphasize that this is a risk for the right understanding of the requirements and for the successful release of the project.
Filed Under Business Analysis | 2 Comments
Walking on Water
I found this great sentence, which belongs to Edward V. Berard and I am eager to share it with you:
Walking on water and developing software from a specification are easy if both are frozen.
Thanks to Irina Marudina for this piece of wisdom.
If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email
Filed Under Fun, Software Development | 2 Comments
-
-
Subscribe to this blog!
-
License
The content of this site is licensed under a Creative Commons Attribution- Noncommercial- No Derivative Works 2.5 Bulgaria License -
Admin