Project Management

Project management is the discipline of carefully projecting or planning, organizing, motivating and controlling resources to achieve specific goals and meet specific success criteria. A project is a temporary endeavor designed to produce a unique product, service or result with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables) undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value.

Share tech news, updates, or what's on your mind.

Sign up to Post

This Article basically defines how to advance or boost you software testing process. what are the best practices to strengthen your testing procedures? to learn in-brief do read further
When it comes to building apps, it's more than just writing code. And unfortunately, many people (and companies) forget that. In fact, the raw time it takes to build the app itself is only half the battle.
Starting a business requires forethought, planning and preparation. As eager as you are to get started with business activities, you need to walk through a few important steps to ensure that your business gets off on the right foot.
Even though starting and growing a lucrative business while you’re still in college sounds impossible, it is actually quite conceivable. There are several reasons why this is the perfect time to start a new venture.

Expert Comment

by:Craig Kehler
Great article. One of our employees who went to Cal Poly did just that and they were very successful.
Successful collaboration among team members is essential for the growth of your business. When employees work together on projects, share ideas and communicate effectively they get better results.
Read about why it is more lucrative for an IT company to participate in government projects.
Read about the ways of improving workplace communication.

Expert Comment

by:Brian Matis
Great article, Oscar! This is a topic becoming incredibly important to me. I love how many new sorts of techniques and tools there are for fostering improved communication, but it's definitely in a major transitional period. There are so many options! I've had to figure out things like what type of communication preferences different people have, to try to make sure I'm using the one that they prefer. Like how some people prefer email and rarely check chat, whereas others can be the exact opposite! Exciting times for sure...

I also love your mention of team building activities. One idea I've toyed with is using cooperative style board games, such as Pandemic. Wondering if anyone else has tried things like that?
When you’re making plans to join the modern business race, you should analyze various details that may affect your results. Nowadays, millions of businesses are trying to grow into established and appreciated professional enterprises.
A simple overview of the possibilities of using technology for project management.
Learn how ViaSat reduced average response times for IT incidents from 10 minutes to 30 seconds.
In this article, you will read about the trends across the human resources departments for the upcoming year. Some of them include improving employee experience, adopting new technologies, using HR software to its full extent, and integrating artificial intelligence into the HR department.
"Disruption" is the most feared word for C-level executives these days. They agonize over their industry being disturbed by another player - most likely by startups.
Transparency shows that a company is the kind of business that it wants people to think it is.
Online collaboration can help businesses be more efficient, help employees grow their skills and foster a team environment.
Communication between departments might not happen in two different languages, but they do exist in two different worlds. With different targets and performance goals the same phrase often means something completely different to each party. Learn how to work across these barriers in this article.

Expert Comment

by:Yashwant Vishwakarma
Good article dude :), voted yes :)

Expert Comment

Makes total sense and I've experienced the effect exactly as described of several of these elements, both when applied and when missing. Nice reminders, well composed thanks.
You can provide a virtual interface for remote stakeholders in a SWOT analysis through a Google Drawing template. By making real time viewing and collaboration possible, your team can build a stronger product.

Author Comment

by:Sina May
Our org has a Google Apps account which made Drawings a bit more accessible. I could definitely see a company with Office 365 going with OneNote instead.  :)

Expert Comment

by:Deborah Canales
What a nifty idea! My company utilizes Google Apps so I will have to keep this in mind to share with my users. :) Thanks!
Agile and Scrum have almost become synonymous. Have you wondered what's the difference? Scrum is just one way to be Agile. It is the most popular which leads to the common confusion. Agile actually refers to a philosophy shared by group of development methods, each offering a unique approach.
LVL 15

Expert Comment

by:Eric AKA Netminder
Documentation is a big contentious issue in Agile. There is a reason for this. When you start your presentation on Agile you start by going through the 4 statements of agile manifesto. As soon as you go to the second statement, traditional waterfall guys start frowning their eyes. The second statement in the manifesto says this.

Working software over comprehensive documentation
Seeing the statement people assume that documentation is not part of the agile process. It completely ignores documentation. Here comes questions. Without documenting the process flow how do you know what is the process we need to follow? Without document how do you know what is the requirement? Without document how do you know what has been implemented? Without document how is a new dev/qa going to understand what is coded/system all about? And if it is someone from CMMi background, then god can only help you to convince him/her.
The key thing people forget is that processes are there to help people get their work done faster. Deliver software faster to the end user. Faster delivery will help you capture market compared to your competitors. In software development you are not delivering document to the end user rather a working software. The above statement never said documentation is not needed, just that the emphasis is on delivering value to the end user.
Now let’s try to address some of the questions raised above.
Process flow documentation
In Agile, time and again people ask this question "How would you estimate a release for a product?". When it comes from management they want to know the following:
  • Calculate the man hours which is at their disposal to get to the release date
  • Risk assessment
  • How many people we need, can we expedite the developement if we pump in more man power?
There are many more questions. In some cases they want to use some complex prediction algorithm to come up with the release date. Oh!! My god, I think, at the end of the day who is going to implement the features? Can an algorithm do an exact implementation? Can you use the available man hours?
I would say no. There is danger in using man hours. We don't take into account the diversity of a team. It can have people with experience levels. A person with ten years of experience may be able to finish a task in four hours, while another person with five years may take a day and someone less experienced may take two or more days. How does an algorithm include these differences? Or the team may be comprised of a tester, developer, BA etc. Each one has different work to do and you can't consider everyone to complete the different kind of work in the same hours at their disposal. Many a time management either doesn't understand or doesn't want to come out of its traditional way of running business.
There is an easy solution to this. No fancy algorithm, no man hour calculation, nothing. If you are aware of Agile
I worked at a US software company that used offshore contractors for ten years and offshore employees for three years. We had a positive experience and you can too.
When I interviewed people for positions in the US, I would tell them that we worked with offshore staff. Some of the candidates had experience with this, but none of them had really positive experiences.
Why would you want to work with offshore staff?
  • Reduce expenses, but don’t get too greedy on this. Salaries may be less, but you have additional costs for travel, infrastructure, and inefficiencies.
  • Offshore staff can deploy Internet services during their day, when it is nighttime for your customers.
  • It may take less time to hire software professionals offshore than in some US cities.
  • People can work ‘round the clock on problems.
  • If you have a disaster onshore, the offshore staff can still work and vice versa.
From the beginning, we emphasized building relationships and developing people in addition to getting work output.
To build relationships we travelled. The president, CTO, VP, directors, managers and individual contributors all travelled offshore. The reverse was also true. Managers established regular visits in both directions to build relationships and understanding of environments. Managers went on shorter trips, while individual contributors from offshore spent longer periods in the US.
Develop the offshore staff…
If you are using Scrum Framework or another agile process, a retrospective may be part of it. Does your team perform retrospectives? Are you getting value from your retrospectives?

I see a common anti-pattern when people conduct a retrospective for a sprint or write a root cause analysis for a defect. First they will point out the sequence of events that led to some code executing which caused the wrong thing to occur. Then to prevent that kind of problem from happening in the future they will basically conclude "we will try harder" or "we won't do that next time."

The purpose of a retrospective is to improve your process continuously. First identify something that didn't go well; perhaps it's a defect. Next your team must examine each step of the process which resulted in the defect. For each step think about whether the defect got created in that step and whether the defect escaped detection in that step. Finally, decide what actions to take to improve your process.

For the scrum framework process, you might think about the following.
  1. Did you groom the story in the backlog before adding it to the sprint?
  2. Was the story too big?
  3. Did you rush to finish the story to make the sprint deadline?
  4. Were the acceptance criteria sufficient?
  5. Were the acceptance criteria specific?
  6. Did you write the acceptance criteria together or review them?
  7. Did you add acceptance criteria during the sprint instead of putting them on the backlog?
  8. Did you do Test Driven Development?
It was Monday morning and while heading to work those familiar feelings of frustration began to rise: How was I ever going to get my yard work done?! At the end of every weekend I discovered that I spent more time trying to decide what to work on than actually working. How was I ever going to get to re-landscaping the front yard, prepping my vegetable garden for fall and maintaining the back yard so that the kids and pets could play? At the peak of my frustrations I discovered the Agile Scrum Framework.

Recently, buzzwords like Scrum and Agile were being tossed around the office. After educating myself by watching tutorials and reading, I immediately thought of my yard and how I could use the Agile Scrum Framework to accomplish my work!

Agile is a concept for software development cycle defined in the 80s by Hirotaka Takeuchi and Ikujiro Nonaka. Scrum is one way to adopt Agile that allows developers to be more flexible in reaching attainable goals. It breaks down like this: A team of cross discipline producers get together with a Project Owner and Scrum Master (a Scrum Master makes sure things stay on track but doesn't do any actual work) and decide what can be completed in a sprint (interval of time). Before sprinting user stories are used to define what needs to be done. Those user stories are broken down into tasks that can be accomplished during the sprint. These are backlog items. For more info on Scrum check out this great video series

Expert Comment

by:Jigs Gaton
Helpful way to understand Agile, thx.

Expert Comment

by:Jigs Gaton
Oh, and by the way, to answer your question in the last para:
Have you used Agile Scum? How?
I can only say,  "As consultants."
Cobalt Digital Marketing began using the Scrum Framework development process in summer 2009.  We hired a consultant to train the teams, observe meetings, and answer questions.

He recommended that we begin using one-week sprints for several reasons.  The team gets feedback quickly.  You fail faster and succeed faster.  You go through the complete sprint cycle many times so you gain experience quickly.

In my experience those made sense in theory and they were valuable in practice during our transition.  The consultant was also able to repeatedly coach the teams to learn agile principles.

You may hear that common practice is to use a two-week or four-week sprint.  Why, after more than two years, do we continue to use one-week sprints?

We plan to release our main application once per week.  The cadence of the sprints matches our release cadence.

The limited amount of time forces teams to create small stories.  We try to limit story size to two days for two people.  Small stories are easier to code review and demo.
Most of our teams have members in both the US and India.  Product managers work in the US.  India staff are hungry for all the communication they can get.  They miss some discussions in the US with the product managers, design sessions, and planning meetings.  The one-week sprint forces the team to communicate more often in planning, backlog grooming, and demo meetings.

Product owners can see progress and give feedback every week.

Business owners …

This article is a requirements document template for an IT reporting project, based on my development experience as an SSRS, Crystal Reports, and Access developer and staff manager over the years.  

For a Requirements Document Template for an ETL Project see my article here

After enough trial and error from the best and worst clients, business analysts, executive sponsors, and my own shining and less-than-shining moments I have seen many developers confronted with poor requirements turn into ... the DEV Nazi!!

The DEV NaziSo to make sure that doesn't happen to you, here's a template for your reporting projects.

In scope for this article

  • A requirements doc template designed for business analysts to cover most reporting projects.
  • Witty advice

Out of scope for this article

(But maybe if you vote Yes and comment nicely at the bottom of this article I'll write another article on it.)

  • Requirements Elicitation
  • Requirements documents specific to other types of projects, such as ETL and Data Warehousing
  • Report Design, especially the new minimalist style that's gaining popularity

So here we go..

Version History

A 'who changed what when' chronology of all changes, either using Word change tracking or lines like 'Bob's changes in yellow highlight'.  Keeps everyone honest when there are lots of changes.


Also known as project objective, business goals, business problem statement, and various other terms.

A simple 'Here's why we're doing this' paragraph.  The target audience being those that are likely to only read this paragraph, but this also gives the developer some design decision guidance.

In Scope / Out of Scope

Everybody LOVES this section!  Okay, developers LOVE this section.  In Scope is a summary of what's in the requirements.  Out of Scope is usually a Top 10 list of things that are close but not in, and answers the often asked question 'Are we also getting this too?'  This is a developer’s best line of defense against scope creep by false or unstated expectations. 

And yes, just because person x told person y a month ago that it’s in requirements, or this email two months ago said it’s in, or was mentioned on the golf course last year during preliminary negotiations means that it’s in.   I've also known more than a couple of clients that will negotiate effort, cost, and time, and then scope creep the hell out of a project in order to make themselves look better.  Been there, dealt with that. 



A statement on when this can be completed, such as 'When division X is in the data warehouse', 'When project ABC is completed', 'Beginning in FY 2013', 'Yesterday', etc.  Helps project managers plan this project within a project management system that deals with all projects, all resources, and available time.

Report properties

  • Name - The name people will call it.
  • Description - 25 words or less.
  • Population - “All x's by y for time period z-1 to z-2”.  Also note if report values are supposed to match any other report.
  • Business Owner(s) - The person that will approve the creation of the report, and likely any future changes.
  • Technical Owner(s) - The person that will build the report, and likely any future changes.
  • Is there a Service Level Agreement (SLA)? - This will dictate how much effort will be done to log report success/failure, does this warrant somebody getting a phone call at two in the morning to fix it, and how many resources should be thrown to break/fix it.
  • Style sheet / cosmetics to use - Usually in the form of 'make this look like..'
  • Exact source of data if known, and if it matters.
  • Page count - Does it absolutely, positively have to fit on one page?
  • Does this report need to be historically reproducable? - If your data is frequently updated or deleted, re-running a report for a prior period may not result in the same exact report as when it was originally ran.
  • Availability - Once a day at 8am, 24/7, etc.
  • Accessibility - How will it be accessed?  Internally, externally, on a boat, with a goat...
  • User Security - Who can view the report.
  • Data Security - Does it contain Personal Health Information (PHI) or Personal Identity Information (PII) that would require protection?
  • Does anything get turned off once this report is placed in production?


User supplied values that will change the population.  For each parameter

  • Name as it would appear on the screen
  • Format - Number, date, text, etc.  Also is it free-form text, or populated from a range of values?
  • Cascading - Are parameter 2 values dependent on what is selected in parameter 1?
  • Should an ‘All’ option be added?
  • Can users select multiple values?
  • User security - Does any of the above require users to have access to only a specific set of parameters, such as the Seattle boss can only run it for Seattle?
  • Time period - Will this report ever need to be run for a specific date or range of dates?



  • Will usually be dictated by style.  Frequent header items are the company logo, formal name, report number if it exists, and any parameters that were used to generate the report.



For each section

  • How is it populated - Especially if sections are populated differently.
  • Drill down - Click or mouse over something and details either appear below it
  • Grouping, including header and footer info.
  • Sorting - Default sort order, which columns are sortable, and any special sort order other than 0-9 or A-Z.
  • Links to other reports - If there are multiple reports and links between them, a map is an excellent idea. Each ‘other report’ would require its own requirements doc.
  • Alternating background color - Makes the report easier to read.

For each column

  • Name
  • How populated - Single value, a defined calculation such as 'Beginning inventory for the month + Purchases - Sales'
Fun fact:  Providing a PowerPoint presentation from some VP and saying 'these numbers are just to illustrate the concept' is not a good requirement for a calculated column. Trust me on this one.
  • Data Type - Numeric, Currency, Date, Text.  Also other formatting info such as decimal places, dollar sign, thousands separators, and negative number handling.
  • Borders - Around all cells, none, heavy borders on certain sections.
  • Conditional Formatting - Make the color of bad stuff red, good stuff green, etc.

Does any part of the report have to match other parts of the same report?  (i.e. Sum of Dollar Amount matches ‘Grand Total’ text box)


  • Will usually be dictated by style.  Frequent footer items include page number, date/time of generation, and a legal notice.


Automated Execution

  • Time period - Monthly, daily, immediately after another process completes
  • Delivery method - Email, Excel, etc.
  • Distribution List - Who gets the report?
  • Data Security - Does the report need to be encrypted/decrypted?

Manual Execution

  • Where does the user go to execute it?


  • Are reports archived - Where, and for how long…
  • If yes, is there a reason why - SOX, ISO 9000, CIA, Company Policy, etc.

Are requirements easily understood?

Any confusion in requirements is going to be defined differenty by different people, resulting in time and effort, and goodwill if that confusion is between you and the client. 


A big honkin' list of other quantifiable things you may need to directly address

Availability, Capacity, Data Currency, Data Retention, Degradation, Deployability, Exception handling, Extensibility (flexibility), Internationalization, Interoperability, Audit logs, Maintainability, Portability, Privacy, Recoverability, Reliability, Response time, Scalability, Security, Upgradeability, Usability.

NOT to be confused with these MBA Buzzword Bingo words, which may sound real impressive but have no quantifiable characteristics whatsoever:

World-class, best of class, best of breed, industry leading, empowerment, collaboration, repurpose, frictionless, client-focused, ecosystem, excellence, synergize, geo-targeted, diverse, environment, core competency...


And finally :: drum roll ::  Top 10 extra tips for writing requirements docs...

10   If requirements documents were easy, they'd offshore both the requirements and development for a third of what you cost, so don't get bent out of shape when things are complicated.  It's job security.

9      Never underestimate the awesome power of a :: blank stare :: to get people to provide you with better requirements

8      Sometimes 'draw me a sketch' is an excellent place to start requirements elicitation.

7      Never assume customers know exactly what they want.  Sometimes you have to guide them to the answer.

“If I had asked people what they wanted, they would have said faster horses.” - Henry Ford

6     Scope Creep - Changes in requirements after the initial ones are approved, but there cannot be an expectation that they will be immediately accepted.  They must be managed with budget, schedule, and resources.

5      Make sure the right stakeholders are defined, included in requirements elicitation, and accountable.  Especially if there are multiple groups that have different opinions on what the requirements should be.

4      You are not an order taker!  (see 'Faster Horses' above).  This means you have to own your expertise and discover your customers needs together

3      Being a Business Analyst is its own career track, with its own training and certification.  The IIBA has plenty of resources.

2      Requirements documents should be signed by all customers.  In blood would be preferable, but in modern times ink is an acceptable alternative. ... and the number one tip for writing requirements docs...

1      Any requirement that is missed, and caught in later stages of development, will cost WAY more money to fix, so make sure you get it all!!

Thank you for reading my article, please leave valuable feedback. If you liked this article and would like to see more, please click the Good Article button near the bottom of this article.  

I look forward to hearing from you. -  Jim  ( LinkedIn )  

The material in this article was presented at SQL Saturday #682, St. Paul Minnesota, 2017.


Expert Comment

by:CamCam Fields
Great article!  As a BA, I have my first external customer wanting a new report (my developers are very excited lol) so this is PERFECT.  Sharing link on our Pulse site!!!
LVL 68

Author Comment

by:Jim Horn
@CamCam Fields - Thanks for the compliment.  It was a fun article to write, and based on a lot of projects where either it was easy BA work, the BA was in the middle of contention between external clients and internal account managers, or where I was the BA by default as there was none.

Project Management

Project management is the discipline of carefully projecting or planning, organizing, motivating and controlling resources to achieve specific goals and meet specific success criteria. A project is a temporary endeavor designed to produce a unique product, service or result with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables) undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value.