250+ Software Requirement Analysis And Specifications Interview Questions and Answers, Question1: What is a software requirements specification? Question2: What is SRS in project? Question3: What is requirement specifications of the system? Question4: What is SRS in software engineering? Question5: What are the requirements of software?
Requirement Analysis, also known as Requirement Engineering, is the process of defining user expectations for a new software being built or modified. In software engineering, it is sometimes referred to loosely by names such as requirements gathering or requirements capturing. Requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements. Here are the objectives for performing requirement analysis in the early stage of a software project:
From What to How: Software engineering task bridging the gap between system requirements engineering and software design.
3 Orthogonal Views: Provides software designer with a model of:
system information (static view)
function (functional view)
behavior (dynamic view)
Software Architecture: Model can be translated to data, architectural, and component-level designs.
Iterative and Incremental Process: Expect to do a little bit of design during analysis and a little bit of analysis during design.
What is Requirement?
A software requirement is a capability needed by the user to solve a problem or to achieve an objective. In other words, requirement is a software capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documentation. Ultimately, what we want to achieve is to develop quality software that meets customers’ real needs on time and within budget.
Perhaps the greatest challenge being faced by software developers is to share the vision of the final product with the customer. All stakeholders in a project – developers, end users, software managers, customer managers – must achieve a common understanding of what the product will be and do, or someone will be surprised when it is delivered. Surprises in software are almost never good news.
Therefore, we need ways to accurately capture, interpret, and represent the voice of customers when specifying the requirements for a software product.
Activities for Requirement Analysis
Requirements analysis is critical to the success or failure of a systems or software project. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Conceptually, requirements analysis includes four types of activity:
Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering.
Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
Requirements modeling: Requirements might be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.
Review and retrospective: Team members reflect on what happened in the iteration and identifies actions for improvement going forward.
Requirements analysis is a team effort that demands a combination of hardware, software and human factors engineering expertise as well as skills in dealing with people. Here are the main activities involve in requirement analysis:
Identify customer’s needs.
Evaluate system for feasibility.
Perform economic and technical analysis.
Allocate functions to system elements.
Establish schedule and constraints.
Create system definitions.
Requirement Analysis Techniques
Requirement analysis helps organizations to determine the actual needs of stakeholders. At the same time, it enables the development team to communicate with stakeholders in a language they understand (like charts, models, flow-charts,) instead of pages of text.
Once the requirements are gathered, we document the requirements in a Software Requirements Specification (SRS) document, use cases or as User Stories, which are shared with the stakeholders for approval. This document is easy to understand for both normal users and developers. Any changes in the requirements are also documented and go through a change control procedure and finalized on approval.
Business Requirement vs Software Requirements
A business plan or project requires a variety of requirements to help define goals and establish a scope for the work that will be undertaken. Requirements also provide context and objective ways to measure progress and success. Once business requirements are established, software requirements are defined and developed in order to move a project forward.
Business requirements relate to a business’ objectives, vision and goals. They also provide the scope of a business need or problem that needs to be addressed through a specific activity or project. For example, if a trade association has an objective to promote the services offered by its members, the business requirements for a project might include creating a member directory that increases awareness of members. Good business requirements must be:
Clear and are typically defined at a very high level.
Provide enough information and guidance to help ensure that the project fulfils the identified need.
Understanding an organization’s mandate, objectives or goals, a specific business need or problem that is being tackled
Should be clearly defined and understood before developing business requirements.
The need or problem can relate to the organization or business in general or focus on a stakeholder group, such as customers, clients, suppliers, employees or another group.
Software requirements break-down the steps needed to meet the business requirement or requirements. Whereas a business requirement states the ‘why’ for a project, a software requirements outline the ‘what’.
For example, if the business requirement is to create a member directory for a trade association, the software requirements will outline who has access to the directory, how member register with the directory, who will have ownership of the data, what vehicle or vehicle will be used such as a website or paper-based directory, and so on.
Techniques for Discovering Business Needs
There are various requirement analyzing techniques that can be used as per the business improvement and software development process. Listed below are some of these techniques.
Gap Analysis Using BPMN or ArchiMate
A gap is often said to be “the space between where you are and where you want to be”. Gap analysis is a comparison process between baseline and target business scenario. In other words, gap analysis is the study of what a business is doing currently and where it wants to go in the future, and is undertaken as a means of bridging the space between them. The goal of the gap analysis is to identify gaps in optimizing performance. This provides a business with insight into potential improvement. It answers questions like what is the current state of the project? Where do we want to be? etc.
ArchiMate – Gap Analysis
ArchiMate is an open and independent enterprise architecture modeling language to support the description, analysis and visualization of architecture within and across business domains in an unambiguous way. It’s a perfect modeling tool and with the required notation to perform gap analysis.
BPMN – As-is and To-be Analysis
The example that we are going to demonstrate is about current situation (as-is process) of an online shop that sells goods. The process begins with the sales representative receives a purchase order from a customer and proceeds to check the stock level. If there is enough stock on hand to meet with the order, the sales representative will pack them. The process ends with shipping them along with an invoice. In case of insufficient stock, the sales representative will suggest the customer to amend the purchase order.
Let’s just say that our business has grown so much that we now have a warehouse to keep our stocks. So we are looking for ways to improve our current (as-is) process to better allocate the new resources. Furthermore, we will show an example of modeling the enhancement below in a to-be process diagram.
Business Motivation Model
If an enterprise prescribes a certain approach for its business activity, it ought to be able to say why and what result(s) is the approach meant to achieve. The Business Motivation Model (BMM) is an OMG modeling notation for support of business decisions about how to react to a changing world. An enterprise would use it by acquiring a BMM modeling tool and then creating its own BMM – populating the model with business information specific to the enterprise. There are two broad purposes:
To capture decisions about reaction to change and the rationale for making them, with the intent of making them shareable, increasing clarity and improving decision-making by learning from experience.
To reference the outcomes of the decisions to their effect on the operational business (e.g. changes made to business processes and organization responsibilities), providing traceability from influencer to operational change.
End – define what an enterprise wants to be – the states it desires to be in.
Means – define what an enterprise has decided it needs to do to achieve its ends.
Influencer – is something that an enterprise decides might affect it.
Assessment – When an influencer causes a significant change, the enterprise makes an assessment of its impact, identifying risks and potential rewards. There may be multiple assessments, perhaps from different stakeholders.
Customer Journey Mapping
Customer Journey Map is a powerful technique for understanding what motivates your customers – what their needs are, their hesitations, and concerns. Although most organizations are reasonably good at gathering data about their customers, data alone fails to communicate the frustrations and experiences the customer experienced. A story can do that, and one of the best storytelling tools in business is the customer journey map.
Customer journey map uses storytelling and visuals to illustrate the relationship a customer has with a business over a period of time. The story is being told from the perspective of customer, which provides insight into the total experience of the customer. It helps your team better understand and address customer needs and pain points as they experience your product or service. In other words, mapping out the customer journey offers your business the chance to see how your brand first engages a potential customer, and then moves through the touchpoints of the entire sales process.
Finally, the team can propose the improvement or actions to be taken against each of the touchpoints. These proposed actions can be potential source of software requirements.
Techniques for Identifying Software Requirements from Business Needs
Data Flow Diagram
A Data Flow Diagram (DFD) can be designed early in the requirement elicitation process of the analysis phase within the SDLC (System Development Life Cycle) to define the project scope. A DFD is often used as a preliminary step to create an overview of the system without going into great detail, which can later be elaborated.
For instance, if there is a need to show more detail within a particular process, the process is decomposed into a number of smaller processes in a lower level DFD. In this way, the Content Diagram or Context-Level DFD is labeled a “Level-0 DFD” while the next level of decomposition is labeled a “Level-1 DFD”, the next is labeled a “Level-2 DFD”, and so on.
A UML use case diagram is the primary form of system/software requirements for a new software program under developed. Use cases specify the expected behaviour (what), and not the exact method of making it happen (how). Use cases once specified can be denoted both textual and visual representation (such as UML). A key concept of use case modeling is that it helps us design a system from end user’s perspective. It is an effective technique for communicating system behavior in the user’s terms by specifying all externally visible system behavior.
A use case diagram is usually simple. It does not show the detail of the use cases.
It only summarizes some of the relationships between use cases, actors, and systems.
It does not show the order in which steps are performed to achieve the goals of each use case.
A standard form of use case diagram is defined in the Unified Modeling Language as shown in the Use Case Diagram example below:
A user story is a note that captures what a user does or needs to do as part of his/her work. Each user story consists of a short description written from user’s point of view, with natural language. Unlike the traditional requirement capturing, user story focuses on what the user need instead of what the system should deliver. This leaves room for further discussion of solutions and the result of a system that can really fit into the customers’ business workflow, solving their operational problems and most importantly adding value to the organization. User stories are well compatible with the other agile software development techniques and methods, such as scrum and extreme programming.
User Stories vs Use Cases – The Similarity
If we consider the key component in both approaches:
User Stories contain, with user role, goal and acceptance criteria.
Use Cases contain equivalent elements: an actor, flow of events and post conditions respectively (a detailed Use Case template may contain many more other elements).
User Stories vs Use Cases – The Difference
The details of a User Story may not be documented to the same extreme as a Use Case.
User Stories deliberately leave out a lot of important details. User Stories are meant to elicit conversations by asking questions during scrum meetings.
Small increments for getting feedback more frequently, rather than having more detailed up-front requirement specification as in Use Cases
A usage scenario, or scenario for short, describes a real-world example of how one or more people or organizations interact with a system. They describe the steps, events, and/or actions which occur during the interaction. Usage scenarios can be very detailed, indicating exactly how someone works with the user interface, or reasonably high-level describing the critical business actions but not the indicating how they’re performed.Usage scenarios are applied in several development processes, often in different ways. In derivatives of the Unified Process (UP) they are used the help move from use cases to sequence diagrams. The basic strategy is to identify a path though a use case, or through a portion of a use case, and then write the scenario as an instance of that path. For example, the text of the “Withdraw Funds” use case would indicate what should happens when everything goes right, in this case the funds exist in the account and the ATM has the funds. This would be referred to as the “happy path” or basic course of action. The use case would include alternate paths describing what happens when mistakes occur, such as there being insufficient funds in the account or the ATM being short of cash to disburse to customers. You would write usage scenarios that would explore the happy path, such as the first scenario above, as well as each of the alternate courses. You would then develop a sequence diagram exploring the implementation logic for each scenario.
Scenario: ATM banking for the week.
Sally Jones places her bank card into the ATM.
Sally successfully logs into the ATM using her personal identification number.
Sally deposits her weekly paycheck of $350 into her savings account.
Sally pays her phone bill of $75, her electric bill of $145, her cable bill of $55, and her water bill of $85 from her savings account
Sally attempts to withdraw $100 from her savings account for the weekend but discovers that she has insufficient funds
Sally withdraws $40 and gets her card back
Scenario: A successful withdrawal attempt at an automated teller machine (ATM).
John Smith presses the “Withdraw Funds” button
The ATM displays the preset withdrawal amounts ($20, $40, and so on)
John chooses the option to specify the amount of the withdrawal
The ATM displays an input field for the withdrawal amount
John indicates that he wishes to withdraw $50 dollars
The ATM displays a list of John’s accounts, a checking and two savings accounts
John chooses his checking account
The ATM verifies that the amount may be withdrawn from his account
The ATM verifies that there is at least $50 available to be disbursed from the machine
The ATM debits John’s account by $50
The ATM disburses $50 in cash
The ATM displays the “Do you wish to print a receipt” options
John indicates “Yes”
The ATM prints the receipt
As you can imagine, there are several differences between use cases and scenarios. First, a use case typically refers to generic actors, such as Customer, whereas scenarios typically refer to examples of the actors such as John Smith and Sally Jones. There’s nothing stopping you from writing a generic scenario, but it’s usually better to personalize the scenarios to increase their understandability. Second, usage scenarios describe a single path of logic whereas use cases typically describe several paths (the basic course plus any appropriate alternate paths). Third, in UP-based processes use cases are often retained as official documentation whereas scenarios are often discarded after they’re no longer needed.Usage scenarios are a major artifact in the Agile Microsoft Solutions Framework (MSF). They are used in combination with personas, descriptions of archetypical users such as John Smith or Sally Jones to explore the requirements for your system. With the Agile MSF you would write either style of usage scenario as appropriate, and you would keep the usage scenario only if your stakeholders are willing to make that investment in the documentation. The Agile MSF has been influenced by Agile Modeling, including the practice Discard Temporary Models.
Software requirements specification establishes the basis for an agreement between customers and contractors or suppliers on how the software product should function (in a market-driven project, these roles may be played by the marketing and development divisions).
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the code is improved so that the tests pass. This is opposed to software development that allows code to be added that is not proven to meet requirements.
TEST DRIVEN DEVELOPMENT (TDD) approach first, the test is developed which specifies and validates what the code will do. In simple terms, test cases are created before code is written. The purpose of TDD is to make the code clearer, simple and bug-free.
Test-Driven Development starts with designing and developing tests for every small functionality of an application. TDD instructs developers to write new code only if an automated test has failed. This avoids duplication of code. The full form of TDD is Test-driven development.
The simple concept of TDD is to write and correct the failed tests before writing new code (before development). This helps to avoid duplication of code as we write a small amount of code at a time in order to pass tests. (Tests are nothing but requirement conditions that we need to test to fulfill them).
Test-Driven development is a process of developing and running automated test before actual development of the application. Hence, TDD sometimes also called as Test First Development.
TDD is neither about “Testing” nor about “Design”.
TDD does not mean “write some of the tests, then build a system that passes the tests.
TDD does not mean “do lots of Testing.”
TDD Vs. Traditional Testing
TDD approach is primarily a specification technique. It ensures that your source code is thoroughly tested at confirmatory level.
With traditional testing, a successful test finds one or more defects. It is same as TDD. When a test fails, you have made progress because you know that you need to resolve the problem.
TDD ensures that your system actually meets requirements defined for it. It helps to build your confidence about your system.
In TDD more focus is on production code that verifies whether testing will work properly. In traditional testing, more focus is on test case design. Whether the test will show the proper/improper execution of the application in order to fulfill requirements.
In TDD, you achieve 100% coverage test. Every single line of code is tested, unlike traditional testing.
The combination of both traditional testing and TDD leads to the importance of testing the system rather than perfection of the system.
In Agile Modeling (AM), you should “test with a purpose”. You should know why you are testing something and what level its need to be tested.
What is acceptance TDD and Developer TDD
There are two levels of TDD
Acceptance TDD (ATDD): With ATDD you write a single acceptance test. This test fulfills the requirement of the specification or satisfies the behavior of the system. After that write just enough production/functionality code to fulfill that acceptance test. Acceptance test focuses on the overall behavior of the system. ATDD also was known asBehavioral Driven Development (BDD).
Developer TDD: With Developer TDD you write single developer test i.e. unit test and then just enough production code to fulfill that test. The unit test focuses on every small functionality of the system. Developer TDD is simply called as TDD.The main goal of ATDD and TDD is to specify detailed, executable requirements for your solution on a just in time (JIT) basis. JIT means taking only those requirements in consideration that are needed in the system. So increase efficiency.
Scaling TDD via Agile Model Driven Development (AMDD)
TDD is very good at detailed specification and validation. It fails at thinking through bigger issues such as overall design, use of the system, or UI. AMDD addresses the Agile scaling issues that TDD does not.
Thus AMDD used for bigger issues.
The lifecycle of AMDD.
In Model-driven Development (MDD), extensive models are created before the source code is written. Which in turn have an agile approach?
In above figure, each box represents a development activity.
Envisioning is one of the TDD process of predicting/imagining tests which will be performed during the first week of the project. The main goal of envisioning is to identify the scope of the system and architecture of the system. High-level requirements and architecture modeling is done for successful envisioning.
It is the process where not a detailed specification of software/system is done but exploring the requirements of software/system which defines the overall strategy of the project.
Iteration 0: Envisioning
There are two main sub-activates.
Initial requirements envisioning.It may take several days to identify high-level requirements and scope of the system. The main focus is to explore usage model, Initial domain model, and user interface model (UI).
Initial Architectural envisioning.It also takes several days to identify architecture of the system. It allows setting technical directions for the project. The main focus is to explore technology diagrams, User Interface (UI) flow, domain models, and Change cases.
Iteration modeling:Here team must plan the work that will be done for each iteration.
Agile process is used for each iteration, i.e. during each iteration, new work item will be added with priority.
First higher prioritized work will be taken into consideration. Work items added may be reprioritized or removed from items stack any time.
The team discusses how they are going to implement each requirement. Modeling is used for this purpose.
Modeling analysis and design is done for each requirement which is going to implement for that iteration.
Model storming:This is also known as Just in time Modeling.
Here modeling session involves a team of 2/3 members who discuss issues on paper or whiteboard.
One team member will ask another to model with them. This modeling session will take approximately 5 to 10 minutes. Where team members gather together to share whiteboard/paper.
They explore issues until they don’t find the main cause of the problem. Just in time, if one team member identifies the issue which he/she wants to resolve then he/she will take quick help of other team members.
Other group members then explore the issue and then everyone continues on as before. It is also called as stand-up modeling or customer QA sessions.
Test Driven Development (TDD).
It promotes confirmatory testing of your application code and detailed specification.
Both acceptance test (detailed requirements) and developer tests (unit test) are inputs for TDD.
TDD makes the code simpler and clear. It allows the developer to maintain less documentation.
This is optional. It includes code inspections and model reviews.
This can be done for each iteration or for the whole project.
This is a good option to give feedback for the project.
Test Driven Development (TDD) Vs. Agile Model Driven Development (AMDD)
TDD shortens the programming feedback loop
AMDD shortens modeling feedback loop.
TDD is detailed specification
AMDD works for bigger issues
TDD promotes the development of high-quality code
AMDD promotes high-quality communication with stakeholders and developers.
TDD speaks to programmers
AMDD talks to business analyst, stakeholders, and data professionals.
TDD non-visually oriented
AMDD visually oriented
TDD has limited scope to software works
AMDD has a broad scope including stakeholders. It involves working towards a common understanding
Both support evolutionary development
Example of TDD
Here in this example, we will define a class password. For this class, we will try to satisfy following conditions.
A condition for Password acceptance:
The password should be between 5 to 10 characters.
First, we write the code that fulfills all the above requirements.
Scenario 1: To run the test, we create class PasswordValidator ();
We will run above class TestPassword ();
Output is PASSED as shown below;
Scenario 2: Here we can see in method TestPasswordLength () there is no need of creating an instance of class PasswordValidator. Instance means creating an object of class to refer the members (variables/methods) of that class.
We will remove class PasswordValidator pv = new PasswordValidator () from the code. We can call the isValid () method directly by PasswordValidator. IsValid (“Abc123”). (See image below)
So we Refactor (change code) as below:
Scenario 3: After refactoring the output shows failed status (see image below) this is because we have removed the instance. So there is no reference to non –static method isValid ().
So we need to change this method by adding “static” word before Boolean as public static boolean isValid (String password). Refactoring Class PasswordValidator () to remove above error to pass the test.
After making changes to class PassValidator () if we run the test then the output will be PASSED as shown below.
Advantages of TDD
Early bug notification.Developers test their code but in the database world, this often consists of manual tests or one-off scripts. Using TDD you build up, over time, a suite of automated tests that you and any other developer can rerun at will.
Better Designed, cleaner and more extensible code.
It helps to understand how the code will be used and how it interacts with other modules.
It results in better design decision and more maintainable code.
TDD allows writing smaller code having single responsibility rather than monolithic procedures with multiple responsibilities. This makes the code simpler to understand.
TDD also forces to write only production code to pass tests based on user requirements.
Confidence to Refactor
If you refactor code, there can be possibilities of breaks in the code. So having a set of automated tests you can fix those breaks before release. Proper warning will be given if breaks found when automated tests are used.
Using TDD, should results in faster, more extensible code with fewer bugs that can be updated with minimal risks.
Good for teamworkIn the absence of any team member, other team members can easily pick up and work on the code. It also aids knowledge sharing, thereby making the team more effective overall.
Good for DevelopersThough developers have to spend more time in writing TDD test cases, it takes a lot less time for debugging and developing new features. You will write cleaner, less complicated code.
TDD stands for Test-driven development. It is a process of modifying the code in order to pass a test designed previously.
It more emphasis on production code rather than test case design.
Test-driven development is a process of modifying the code in order to pass a test designed previously.
In Software Engineering, It is sometimes known as “Test First Development.”
TDD includes refactoring a code i.e. changing/adding some amount of code to the existing code without affecting the behavior of the code.
TDD when used, the code becomes clearer and simple to understand.
I’ve made a list of the 15 core skills that I think project managers need. These are the things that should be part of your skillset because they will help you get the job done more effectively. And for the avoidance of doubt, ‘effectively’ means faster and with less effort. I certainly want that for my projects!
Here is the list of skills project managers need. As you read through, think about which ones should be your focus areas for the coming year and how you are going to take your skills to the next level.
Project leadership was a hot topic this year. Being able to lead your team as well as manage them is a trend that shows no sign of abating (and that’s a good thing). It’s really important to be able to inspire others, set the vision and lead effectively, so if that’s not your strong point resolve to work on it now.
It would be lovely if everyone did what was best for the greater good at all times, but projects don’t work like that in real life, do they? Project managers with good negotiation skills will be an asset to their teams as they seek to resolve conflicts by finding the win-win scenarios for everyone.
It should go without saying that project scheduling is a core project management skill. However, speaking to people who manage project managers during end-of-year review time I have heard that some of them aren’t up to scratch in this area.
Get to grips with project scheduling because a) it’s your job and b) it will help you deliver things more successfully for others (which is also your job).
4. Cost Control
Budget management is bizarrely one of my favourite topics. I am not a natural maths whizz but I do like a well put together spreadsheet. If I understand the numbers and create my own tracking mechanism I can tell you to the penny how much my project is spending.
Cost management is a critical topic for project managers. Those without this skill will be at a disadvantage because budgets are tight. You need to show that you can deliver your project within the cost constraints and by managing the project finances intelligently.
5. Risk Management
The more mature project management gets as a profession, the more we find ourselves doing projects that are unique. The more ‘routine’ the project, the more it is likely to get outsourced or given to a functional manager who shows an aptitude for getting things done. Project managers will work on the more complex, transformative, unique endeavours that require decent risk management.
Being able to control risk (as far as you can) is a sign that you are on top of your project. Project sponsors hate surprises and good risk management is one way that you can manage that.
6. Contract Management
Part of managing your project involves managing suppliers. The vast majority of projects will have an element of supply, whether that is something as simple as the outside caterers who bring in cakes for your launch event or a full-on off-shoring system development firm.
Contract management is about being able to actively manage those procurements. Previously many project managers have been able to rely on their Finance departments to get this sort of work done (and Legal teams for managing the terms of the deal). Today, with everyone under pressure to do more with less, it’s falling to project managers to pick up the slack when it comes to procurement.
7. Critical Thinking
Critical thinking is core to being able to make good decisions. You have to weigh up the pros and cons of solutions to problems before choosing the right way forward. This is what distinguishes a project manager who is good at managing issues to someone who blows issues out of the water every time.
You can build your critical thinking skills through practice and by equipping yourself with tools and approaches to help you structure arguments logically and see things from all angles before making the final decision.
If I had to pick one skill on this list to focus on this year it would be communication. We don’t do enough of it. Our stakeholders demand more of it. We fail time and time again to meet expectations largely because we failed to communicate effectively and often.
Think creatively about the communication channels you have got available to you including:
Collaboration and social media tools
Web and online conferencing.
Then think about how you can apply each of these to actively serve your project next year.
9. Project Recovery
I hope you don’t have to do project recovery next year but if you are looking for a boost to your career then showing you know how to turn around a poorly performing team and project will certainly set you aside from your peers.
Most of the people on your project team won’t work for you (if, indeed, any of them do). That makes it really important that you are good at managing in a matrixed environment but also that you are good at coaching. Why? Because they may not have much project experience and you’ll have to coach them to top performance.
If you are worried about not being a good coach you might be surprised to learn that coaching skills are something that might be closer in reach than you expect. If you sit with a child during homework and help them come to the right answers then you are doing a form of coaching. Some training in this area will help you apply those skills in the workplace to help your team perform their best.
11. Task Management
This is another bread and butter task for project managers. You should be able to create a task list, delegate work to others and keep on top of progress. I found this was the easiest part of project management when I started because I was naturally a list-maker. If it doesn’t come easy to you you’ll have to develop strategies to ensure you are always on top of your To Do list.
When you have cracked managing your own work you can help others manage theirs. This is the best way in my experience to make sure that projects come in on time and others take responsibility for their deliverables.
12. Quality Management
Quality management ensures that you deliver a product that is fit for purpose. What project sponsor doesn’t want that? Unfortunately project managers often don’t spend enough time on the quality angle of their projects – it’s one of those processes and set of tasks that are overlooked as an administrative overhead.
If you are a quality expert, then good for you. But if you aren’t, seriously consider upping this on the priority list for 2015. The better the quality of your deliverables, the better value you are offering stakeholders and the more satisfied they will be.
13. Meetings Management
How many of your meetings this year have overrun or finished without any clear action being agreed? How much time have you sat in meetings wondering why you were there and what time you can leave without it looking too bad? Or worse, how much time have you spent on conference calls only half listening while doing your emails or playing Candy Crush?
Being able to sense when a meeting is going off the rails and people aren’t paying attention is a key skill for project managers. It’s helped by sticking to the agenda but it’s also about being able to read the body language of people in the room to check that you are getting through the material quickly and comprehensively. Don’t let 2015 become another year of wasted time in meeting rooms.
14. Business Case Writing
With the ongoing focus on delivering business value, being able to write a business case (or at least contribute one) will be a good skill to have. Get hold of some templates so that when you are asked to finalise a business case or review one you know what should be included.
Find some business cases from past projects and evaluate what you would do differently. And make sure that your next project actually has a business case – that’s a good start!
15. A Sense of Humour
Getting through your projects largely relies on a good sense of humour and the goodwill of colleagues prepared to pick up the slack or wait another 24 hours.
An ability to see the funny side of project management will keep you on an even keel during the next 12 months.
Now you have read the list which of these skills will you work on as a priority this year? Let us know in the comments and good luck in your project management career this year.
More often than not, the timeline will be revised several times over the life of a project, as priorities change and new requirements are added to the scope. Here again, advanced project management tools like Clarizen are essential, as they allow managers to update the timeline and communicate the changes with ease.