Please feel free to share project and portfolio management articles!
8 thoughts on “Blogorama!”
Don’t pretend to be a project manager when what you really need to be is a Project Leader. In my experience, a Project Manager should only be a title you put at the bottom of your email signature. Project Leaders deliver successful projects.
A Project Leader is a person that puts aside self-interest in favour of the interests of the organisation, stakeholder, and team. A Project Leader does not try to manage the team by telling them the tasks that they need to complete or when to complete those tasks.
A Project Leader sets out the goal and then watches the team fulfil that goal. A Project Leader guides and nourishes a team in order to make sure the project is successful. A leader’s role is to support the project team and stakeholders in becoming self-sustaining and evolving in a positive manner. A Project Leader’s job is done when they are no longer needed, and the project, team, and stakeholders are running on autopilot.
Planning and executing any type of organizational change must begin with an understanding of and respect for the office culture. This can be especially difficult in environments where the culture is resistant to change. Often, higher-level managers will find lots of excuses for not making a change, usually couched in the triple constraint: The change will be too expensive, time-consuming or out of scope.
To begin the change process, especially if the change involves moving from a traditional Waterfall methodology to a more iterative or Agile approach, a project manager must be ready to counter the objections related to the triple constraint. Sometimes, the best way to do this is by example: Use a small, non-mission-critical project as a proof of concept. Measurable success using an iterative approach on a small project can go a long way toward organizational acceptance.
It is important, not only to start with a small project, but also to start with small changes. Rather than adopting a new Agile methodology, it is easier to introduce an iterative approach. For example, instead of instituting Scrum with its ceremonies and artifacts, why not try organizing the development and testing into sprints? Scrum-but isn’t necessarily a poor excuse for Scrum; it can lead the way to adopting Agile development.
Finally, it is helpful to find an “angel,” a senior-level executive who is not resistant to change and is open to and supportive of Agile or the iterative approach. The angel will be the senior manager who gives the go-ahead and supports the proof of concept. Resistance to change within an organization comes from change-resistant people, and when change is supported at the highest levels of management, eventually those who are resistant to change will buy in or leave the organization.
Remember, you are either part of the solution OR part of the problem!
Two things I hate; being late and tracking my time. Last night, my cousin the lowest part of her week is when she has to track time. What makes time tracking such a drag?
Why Employees Hate to Track Their Time – And What You Can Do About It
My company sells employee time tracking software that automates client billing, project accounting and payroll. We have implemented these systems for customers repeatedly where the employees previously were unaccustomed to accounting for their time. Occasionally this has generated some intense emotions. Some people really don’t want to track their time even when their managers are very firm.
Why is this? Why do people find tracking time so unpleasant, or even maddening?
And how about you? Do you like entering data into forms? Why or why not? Is tracking time any worse than filling out other forms?
My experience has shown that it often is for several reasons.
Reason One: Reporting time can threaten status. For salaried people, especially if they’ve been employed earlier in their life in an hourly “time clock” environment, reporting time can make them feel demoted. Conventional wisdom (that I disagree with) is that “professional” people are more trustworthy and less in need of supervision than “blue collar” people.
Reason Two: “What if I find out that I don’t work as much as I like to think?” Some people, often the most productive people, garner self-esteem from the large number of hours they work. But sometimes they’re not sure if they believe their own braggadocio and the thought of finding out the truth is scary.
Reason Three: Time is an imperfect metric for effort or productivity. Knowledge workers know that managers, who have the power to reward some people over others, often forget the vague and aggregated metrics of real productivity in favor of some simple numbers that are tangible, like time records. Managers may take the easy path of rewarding based on time spent rather than develop more subtle and appropriate metrics of real productivity. (Hint: don’t do this)
Reason Four: “I’m too busy” The most responsible and busy employees – the most productive ones whose time is in highest demand – will, sooner or later, always have to stop doing the primary mission of the company to fill out a timesheet. The star employees tend to procrastinate regarding this task, subordinate it or even refuse to do it. Or worse, they’ll create flawed records. On the other hand, the malingerers and marginal producers will often create perfect time records and never submit them late. This fact of life creates an impression in the minds of both that the whole exercise is worthless.
Reason Five: “I’ve procrastinated too long – and now I don’t remember what I did last week.” Procrastination results in useless time records. Who remembers what they had for lunch one day last week? When information – which was mostly made up – is eventually recorded about how much time was spent and on what, it often tends to understate the real accomplishments of the workweek. Reviewing this record can be demoralizing.
So – newsflash – it’s an imperfect world. And people hate tracking their time for many reasons. But how can you possibly run a project oriented organization, especially one that bills for it’s time, without time accounting? The answer is that, in this increasingly competitive world, you can’t, at least not for long. If you don’t get every hour billed that should be, or if you don’t know which projects are profitable and which ones aren’t, you’re going down. Hard. Because somewhere in your numerous and growing array of competitors is a company that’s getting it right. Your only choices are to follow or fail. Or you could lead – and be the first one to get it right.
So let’s look at some ways to overcome all this employee resistance to time tracking.
Education and Buy-In: I am a free market capitalist. So naturally I always think that the most effective way to get people to do something is to make sure they understand what’s really and truly in it for them. And there must be something – something that matters – in it for them.
• In the case of payroll for hourly workers, the desire to get paid fairly for every hour they actually work provides the incentive.
• In the case of billing automation, it’s revenue for the company (i.e. a successful company). Most people can understand this, and they care about the success of their company. If your employees do not care about the success of your company, timesheets won’t help you. You have to go back to the basics of creating a moral and compelling vision of how your company helps humanity (or fluffy bunnies, or whatever.) In the absence of having that strong vision, “bonusing” employees for their success in some intelligent way is usually helpful, although often fraught with opportunities to misstep.
• Project accounting is more abstract than payroll or billing. If done badly, it can lead to unnecessary overtime, stressful blown schedules, bad estimates and cancelled projects. Relating specific examples from your company in which good time collection could have prevented problems helps to get employees on board.
Adoption Dashboard: It helps to include graphs that clearly illustrate which departments and people are entering their time consistently and completely, and which are not. This helps managers understand early on who they need to badger about getting their time recorded, or who to reward for doing a good job in this area.
Phased Rollout: Adopting a multiphase rollout approach that leads to per-person per-project profitability allows you to change the culture in more manageable steps.
Incentives: Linking bonuses or other benefits with complete data collection is often used in customer relationship management (CRM) tools to adjust sales commissions. The same can be done for other forms of data collection. My company, Journyx Inc., has a patent—we call it the ‘frequent flyer patent’—for automatically rewarding your employees on your behalf for timely time reporting.
Email Reminders: Getting an automated reminder when your time has not yet been entered produces results…usually! Some percentage of people will become more timely with their data entry via this method. But be careful about overdoing the number of automated emails that you send. People will naturally start ignoring them if you send too many.
Implementing Project Accounting: If you have more than five people in your organization and they are working on many projects or within many processes, it is time to start thinking about implementing time tracking. If you have 100 people in an R+D group and you’re not tracking time, then you’re wasting the lives and work of a significant percentage of your employees. You might have them working on projects that the market will not reward you for, which are over budget or otherwise in the ditch, and you don’t know that today.
The new mantra of IT seems to be “do more with less,” but how does that work in practice? Is it possible for CIOs to slim down their IT staffs and still meet the high expectations of business users?
To get the answers, we talked with a half-dozen CIOs who run IT shops that are small by design, with a dozen or so employees. Even more than their bigger counterparts, these shops are using cloud computing, SaaS and outsourcing to offload infrastructure tasks and focus on the essentials of the business.
“This is a golden era for small IT departments,” says Reed Sheard, CIO at Santa Barbara, Calif.’s Westmont College, who manages a staff of 15. “With the cloud, I can do things now that only shops with lots of people and money could do before. Now I can play at an enterprise level. It’s a huge opportunity.”
These leaders of small departments offer five pieces of advice that even big shops can learn from, relating to agility, prioritization, staffing and vendor management.
1. Small makes agility easier – sometimes
For the head of a small IT department, “the opportunity to be nimble exists to a much larger degree than in a multinational corporation,” says Sheard. “I can get everybody in the same room at once.”
It’s not just proximity to staff; it’s also the proximity to the business. “It’s our responsibility to empower the college’s larger mission. That proximity to the heartbeat of the organization is advantageous because I can walk across the hall or across campus in just a few minutes to have a meeting.”
That nearness helped Sheard in a recent situation. Facing exponential growth in storage needs, he initially thought about simply expanding the organization’s existing storage-area network, even though his team found the software to manage it increasingly complex.
Based on his own experience and insights from other college officials, he knew that offsite access into the legacy storage system was difficult. He started running the numbers and quickly discovered that for the same cost of the SAN and its needed expansion, he could just as easily move to a cloud-based storage system. “We were able not just to fix the problem, but to look two or three steps down the road” to where mobile access was going to be in increasing demand, he says.
There can be a downside to agility, however. “Because we’re small, we feel we’re more agile,” says David Cooke, director of technology at Altum Inc., a Reston, Va.-based developer of grant-management software. Cooke has an onsite team of 12 and an offshore team of six. “If an opportunity appears, we tend to go aggressively at it,” he says. “That can drag individuals in different directions.”
Cooke’s situation highlights a scenario that can be a challenge in a small IT department. “Getting a small department to adopt process is tricky, because the tendency is to want to turn on a dime. You have to draw a fine line on how rigid the processes are. We have more processes in place than most companies our size, but they’re probably not as robust as I would like.”
Takeaway for big IT shops: Maintain relationships with peers for better business insight, and remember that processes are there for a reason.
2. Small makes prioritization a must
With a small staff, there’s no margin for error when choosing which projects you pursue. “You don’t have the resources of a large company, so you have to prioritize,” says Chris McMasters, CIO at Honeyville Inc., which has an IT department of six.
Customers of the Rancho Cucamonga, Calif.-based food processing and distribution company include Frito-Lay and Mars M&M. “When Kellogg’s needs us to integrate data, we determine that as a business priority, and focus our resources on it.”
That also means CIOs of small IT departments need to be better managers. “I have to allow my staff to focus on that project and minimize disruptions,” he says. That means giving employees the latitude to say no, they can’t drop what they’re doing because another project already has priority.
“If you protect them, they can finish one project sooner and get to the next one faster. You have to minimize the noise around them,” says McMasters. The alternative is the IT department ends up with a long list of to-do items, and very few are done well.
In the city of Goodyear, Ariz., a suburb of Phoenix, CIO Dan Cotterman (who runs a department of 18) says each department creates its strategic and operational plans based on the city council’s strategic action plan, which specifies what projects they need to accomplish. Then IT builds its roadmap, which helps it establish priorities.
The city used to have a request process that was highly formal and involved triplicates of everything. Cotterman says he has tried to make the process more informal, with weekly meetings with city leadership. “When a request comes in, we see how well it aligns. Usually only a few fit neatly with strategic priorities,” he says.
Takeaway for big IT shops: Identify and maintain priorities so your staff doesn’t feel torn in multiple directions.
3. Small makes staffing harder
The same rules apply for both small and large IT departments: You need staff with both technical breadth and depth. But for a small IT department, breadth may be more important than depth since consultants can be hired to provide technical expertise. Even more important for employees of small IT shops are business savvy and collaboration skills.
“You can’t have silos when you’re small because people are involved in everything,” says Dale Denham, CIO at Geiger, a Lewiston, Maine-based promotional products distributor with 750 employees and 30 people in the IT department. “I prefer not to hire people who only do storage, because they’d become so focused on storage-related goals such as I/O [to the exclusion of all else], they forget to focus on how a business unit accomplishes its goal.”
At the same time, personality conflicts in a small department can be disastrous to productivity. “They don’t have to love each other,” says Altum’s Cooke. “But we’ve had to get rid of people who were strong technically because they caused friction and there were personality conflicts.” His recommendation: Include more co-workers in the interview process to help gauge the compatibility of the applicant. Not a bad idea for companies of any size.
Randy Gross, CIO at the Downers Grove, Ill.-based IT industry organization CompTIA, has a staff of five. With a group that small, he says, if one person leaves and hasn’t documented his or her processes, “you’re in a world of hurt. Everyone has nuances in the way they configure systems, but human nature is not to let anyone touch your toys,” he says. His recommendation: a lot of cross-training, which is a key part of collaboration.
Read about the hottest jobs, industries and cities for IT pay in 2015!
“They have to understand that it’s not one guy coming after your job – it’s making sure the company is in sound shape [regarding business continuity] should something happen to one person. If you treat it like that, they’re more prepared,” says Gross.
When Gross brings on new staffers, they’re trained over three months in the most important disciplines, including networking, security and virtualization. “We’ll open up those areas one at a time to help them understand how they’ve been built, maintained, upgraded and expanded. Then we move to the next discipline.”
Takeaway for big IT shops: With DevOps and software-defined systems becoming more common, cross-training benefits everyone.
4. Take advantage of outsourcing options to focus on the business
The vast array of outsourcing options these days makes it infinitely easier to run a small IT shop, according to several CIOs. With outsourcing, you can craft an internal team that focuses on the business and craft an external team that focuses on technology.
“Cloud computing doesn’t necessarily reduce your resources, but it changes the skill set you need,” says Cotterman, who’s added three full-time positions to the city’s IT department in the past year, two of which are devoted to business analysis. “You’re going from an administration-heavy team to more business analysts, people who can explain technology and steer the business units down the path to the right solution. It helps us be much more customized to their needs.”
Scott Glenn, associate principal for IT Strategy & Operations at the consulting firm Hackett Group, says he believes strongly in this strategy. Maintaining a small IT department that’s good at keeping the data center running is focusing on the wrong thing – because anyone can keep a data center running.
“You need an IT department with an expertise in fixing the business issue,” he says. “You can change who supports the data center. You want people who understand the business in the IT department.”
Glenn stresses another aspect of having a small IT department focus on the business. “Technology changes so rapidly, it’s hard to keep skill sets refreshed,” he says. Internal IT teams can’t stay up on everything, and if they do, CIOs face having a really expensive staff. “Some resources are in high demand. If you hire them, they’ll hold you hostage for 30% more,” he says. “Let that be someone else’s problem.”
If you’re deploying ERP, hire people who are smart about that; ditto for social media or mobility. “You know what [the business] needs, but you need someone to help you understand the technology. Regardless of size, when you have that focus on primarily business-facing and new development, and not on hands-on keyboard support, you can get more done.”
Takeaway for big IT shops: What’s good advice for tiny IT shops goes doubly for big ones – hire IT staffers who know strategy, and source outside the company for particular technological know how.
5. Small makes vendor management crucial
CIOs who are outsourcing a lot of work must devote a greater proportion of their time to vendor and supplier management, whether that means individual IT contract workers or larger IT consulting firms.
Honeyville’s McMasters works with 20 contract workers to augment his staff. “I spend a lot of time on those relationships, because when we need them, they have to understand our business right away. Done right, it’s very powerful. They become part of the business,” he says.
When it comes to large consulting firms, “we don’t always go with the lowest bidder,” says CompTIA’s Gross. “You have to make sure they have the right kind of people and the right mix of people.” He’s witnessed the person with the most knowledge about a system leave the consultancy, which in turn left his company in the lurch. His recommendation: Don’t be afraid to use multiple consulting firms. “Some firms might say they know the whole Microsoft stack, but in reality, they don’t,” he says.
Takeaway for big IT shops: Whether working with individual contractors or large consultancies, maintain close relationships so you’ll have access to the talent you need when you need it.
How big? How small?
One question remains, of course, and that’s how big should an IT department be in relation to the rest of the company? No matter the size of the company, business has always searched for a balance in IT spending. In the past 10 years, reports from research firm Gartner have pegged the ideal ratio of IT employees to all employees at around 5%, although the percentage is significantly higher in some industries, such as financial services.
For small and large IT departments alike, there’s no set percentage. For small companies, what’s most important is that the staff isn’t so small that the departure of a key employee cripples the team or so large that staffers start closing themselves off into silos. While large IT departments have more flexibility in staffing, the same logic prevails: Focusing on cross-training and eliminating silos gives you more flexibility during inevitable staff changes.
Perhaps the best answer comes down to what helps the business most. Grow your internal team based on business needs, and grow your external team based on technology needs. http://www.computerworld.com/article/2918493/it-management/5-lessons-small-it-shops-can-teach-the-big-guys.html?nsdr=true
When and how should a business analyst engage developers during the requirements definition process?
Engaging developers in the requirements definition process seems perfectly natural. After all, even if they are not explicitly involved in the process, developers do define all sorts of requirements as they build software. They make countless decisions (some conscious and some not) about what code is written and how. But generally, such decisions could be improved upon by making them more formal. Business analysts can provide the formal framework in which developers develop technical requirements.
Two common models of gathering requirements persist despite being counterproductive. The first and older model is built around the myth that software development is only about technical programming issues. Development is seen as a black art that can only be done by computer scientists. Thus, the entire development team is comprised of code-minded programmers who may or may not fully understand actual business requirements. This model is beginning to lift as the roles of business analysts, Agile project managers and testers grow more central to the development team.
A second mistaken model remains far more entrenched, but is no less dangerous. Some say requirements are the features of the software to be created. Indeed, developers do have a central role in defining how a product will work; but that actually is a form of high-level design, not requirements. Developers undoubtedly know much more than business folks about data structures, interfaces and other critical elements that must be taken into account for the implemented solution to work properly. However, these elements need to be built on top of a solid base of business-related requirements.
To supplement what developers know, business analysts provide a better understanding of what the business actually requires. Developers may have relevant and valuable business insights. However, that insight is not required for their role and is not their core competency. Work with business analysts first to attain a solid understanding of the business requirements. Then engage with developers to define the software requirements that meet the business’ needs.
The Best Organizations to Work For In Sports (What can we learn from our Athletic Dept that can be applied in OHR?)
So you want a job in sports, but given the choice, what organization is the best to work for?
The sports industry is incredibly competitive, with a high barrier to entry and an even steeper climb to the top. Those that have spent time working in sports know how often organizations turnover employees, whether it be due to the low pay, long hours, slow climbs up the ladder or any number of other factors that dissuade those who enter from having prolonged stays in the industry. Yet many within the industry do end up having long and fulfilling careers, and more often than not, their success can be traced back to the great organizations and leaders that helped shaped them both professionally and personally.
I set out to determine just which leagues, teams, agencies and other organizations within the sports industry set themselves apart from the competition when it came to factors such as employee satisfaction, work-life balance and career growth. I interviewed many dozens of individuals at all levels of sports, from entry-level sales staff to team presidents, as well as top executive recruiters and university leaders who have trained countless generations of top industry professionals.
The organizations that made the list are as different and varied as the industry they represent. Some employee just a few dozen individuals, others many hundreds. Among the areas of the business represented are professional teams like the Cleveland Cavaliers, leagues like the NFL, college athletics departments like the Ohio State University Buckeyes, marketing and consulting agencies like Premier Partnerships and data and research firms such as Turnkey Sports & Entertainment.
It should come as no surprise that during my research, many of the same organizations were mentioned time and again as being the best to work, and an equal many were often labeled as the worst. The differentiating factor between those who were spoke highly of and those that were looked down upon can be summed up in a singular concept – culture. Companies with the highest levels of satisfaction were also the one where employees felt they were more than just a replaceable cog in a giant machine, and where the primary focus of the organization was about creating a positive work environment rather than just the product on the field or the company’s bottom line.
There is no better example of the importance of positive organizational culture than the Arizona Diamondbacks, who were rated extremely high across all categories not just by the team’s actual employees, but also by individuals I surveyed in all areas of the industry.
According to Derrick Hall, the club’s President, “I truly believe that culture is our competitive advantage. We’re in an industry where early entry jobs are extremely difficult, the turnover is devastating and so you have to create a culture where your employees, not the customers, comes first. If the employee feels respected, developed and promoted, he or she will in return treat the customer the same way.”
Successful sports executives like Hall understand that great leadership is not about coming up with all the answers and then convincing your employees to follow your vision. Rather, it’s about having the humility to admit that you don’t have all the answers and then create an environment in which your employees can meaningfully contribute to finding the answers.
To this end, the Diamondbacks have created an operating environment where team employees have a tremendous opportunity to be heard. The club’s staff vote on an “employee of the month” who is then placed on the “Presidents Council”, which meets monthly to discuss key issues facing the organization. From groundskeepers to ticket sales to the front office, every staff member that works for the Diamondbacks has a real opportunity to influence the direction of the organization.
“We involved our employees in all aspects of the organizations decision making process, and make sure that no matter how things are going with the company, they know how much we value them,” explains Hall. “While we can’t control what happens on the field, what we can do is commit ourselves to treating our employees, coaches, corporate partners and fans better than everyone else in professional sports,” he adds.
The Diamondbacks also make giving back to the community a pillar of their organizational identity. The entire team partakes in a quarterly event centered around community service. This level of commitment goes far beyond just engaging with fans, and is at the essence of whom the team’s employees and players are.
“Nothing compares to the pride I have coming to work for the D-backs every single day – the culture within the walls of our organization is contagious, the way we give back to the community is admirable, our leadership team truly cares about the employees, and my co-workers are like family to me,” says Tiffanie Tallman, a member of the Diamondback’s Corporate Partnerships Department. ”But it’s the specific programs we have developed that prove how unique our company culture is to me: the D-backs Give Back League, the monthly all employee meetings including “On the Couch with DHall”, and the Most Valuable Partner Awards are just a few examples of our entire organization coming together to enhance the culture of the most amazing company I can ever imagine,” she elaborates.
Regardless of their size or purpose, each member of my list of Best Organizations To Work For In Sports has developed an incredible reputation in the industry for the positive way they treat their employees. I hope that my findings help both rookies and veterans of the sports business make an educated decision when choosing what organization to work for in a highly competitive and often unforgiving industry.
Jason Belzer is Founder of GAME, Inc. and a Professor of Organizational Behavior and Sports Law at Rutgers University. Follow him on Twitter @JasonBelzer.
Some use the term requirements management to mean the full requirements process, including identifying business requirements and evaluating their content. In my humble opinion, it is more appropriate to restrict the phrase requirements management to the mostly mechanical administrative activities of capturing, categorizing, keeping track of and controlling changes to requirements.
The two aspects do interact, and how they interact is especially relevant for the way Agile requirements are documented. In Agile, the product owner or customer representative typically defines requirements with user stories. A user story very briefly describes something of value to a user or customer and traditionally is written on an index card in the form introduced by Mike Cohn, “As a I so that .” Some teams also include their user story acceptance criteria (brief descriptions written on the back of the index card of how to tell the user story has been met) in the user stories.
Non-Agile development also documents business requirements definitions. Non-Agile teams could, but usually don’t, write them in a user story format yielding one requirement per index card. Initial business requirements documentation formats are not terribly critical for distinguishing between Agile and non-Agile. What happens afterward, though, tends to differ widely between Agile and non-Agile development.
A non-Agile group generally keeps track of all the written requirements throughout the duration of the project and captures written expansions/modifications of them. This process drives the business requirements document down to greater detail or otherwise clarifies them. Non-Agile often actively controls prospective changes to business requirements documents with a change control board or similar body. This body pre-approves requested changes and sometimes also confirms approved changes have been made as approved. Those non-Agile projects that use automated requirements management tools often cross-reference each requirement to where it is used in order to create a traceability matrix. Such a matrix helps confirm that each requirement has been addressed and that development is not creating artifacts that don’t tie to requirements.
There is essentially no Agile requirements document to manage the mental leap from brief user story to executable code.
In contrast, even though the Agile Manifesto does not specifically say it, many Agilistas believe Agile means not writing documentation. These leaders seem to favor writing no more than brief user stories and minimizing time spent on managing such requirements. Agile project teams on their own, without requirements management-type controls, frequently revise user story requirements. Typically, Agile teams break them into smaller user stories that can be implemented in a single sprint iteration. Without managed Agile requirements documents, the original versions can easily be discarded or otherwise lost.
Agile’s next requirements activity is referred to as “conversation.” The developer talks with various stakeholders to learn more about what to build. Typically, the conversations themselves are not recorded in any manageable form. Instead, the developer mentally processes the conversations, mentally designs a program to do whatever the developer thinks needs to be done, and writes the program as designed in his or her head. Often any written user stories are discarded by the time the code is implemented. Thus, there is essentially no Agile requirements document to manage the mental leap from brief user story to executable code. What could possibly go wrong?
EFFECTIVE COLLABORATION achieves what no single team member can on her own. As business magnate Richard Branson said, “A business has to be involving, it has to be fun, and it has to exercise your creative instincts.” The best collaborations do this—optimize each person’s skills by utilizing suggestions from around the table, inspiring cooperation and creative buy-in from all involved.
Here are seven effective ways to create stronger team collaboration.
1. Aggregate and adapt: Any good project manager will bring ideas and plans to the table. The most collaborative will be highly skilled at weaving in the suggestions, ideas and goals of their team for a best-of fusion. Complex, multidisciplinary projects need to employ agile methodologies, involving innovation from all stakeholders and parties to succeed. The use of real-time data to help participants understand what is and isn’t working allows adjustments to be made on the fly. Successful collaboration is an aggregate of the best ideas while remaining adaptive and flexible.
2. Listen first: An effective collaborator knows how to bridge differing ideas into workable solutions. Getting to the root of any new concept or suggestion involves active listening, and listening actively to everyone with a stake in the outcome before mapping a course. Active listening includes giving feedback to confirm and clarify the information that was shared, and having a discussion in real time. A great collaborator will be able to respond most effectively once all parties have been heard. Team members want to feel valued, and being heard is where being valued begins.
3. Energize: The best collaborators assume that others are working smart and working hard. An effective and collaborative leader can bring inspiration and energy into a meeting room or conversation by helping team members feel valued. They sincerely express appreciation for a job well done. When criticism is offered thoughtfully and in the spirit of “your work is important to this project’s success,” effective collaboration becomes second nature. Talking about issues that need to be addressed can be done in a way that gets the team motivated about what’s possible. A motivated, energized team is a project’s strongest asset.
4. Remain open: Great collaborators always keep an open mind and know that brilliant ideas come from the unexpected. Openness is also crucial in building an atmosphere of trust. Workplace relationships are successful when employees are comfortable enough to voice concerns and make suggestions. Satisfied employees comfortably voice concerns and ask questions, and they know where to find the answers. Remaining open to new ideas, accomplishments and thoughtful critique empowers the entire team. The result: Faster problem-solving, healthier teamwork, greater trust and ultimately improved performance.
5. Be Transparent: The most effective collaborators are less concerned with titles and roles than they are with solutions. If a fantastic suggestion is made they give credit where credit is due, regardless of source. Furthermore, effective collaborators clearly define expectations and share information across the board. Clear and inclusive communication allows team members to know that they matter enough to be told the truth. Sharing details with the team increases a sense of workplace community, and adds to the spirit of collaboration. Teams thrive in environments that encourage trial and error and encourage participation.
6. Have fun! Plato is credited with saying that you can discover more about a person in an hour of play than in a year of conversation. An organization or project is more successful when morale, motivation and trust are high. Having fun together—from Tuesday lunches to a bowling night to meetings where humor and optimism have their place—make a positive difference in helping team members from different parts of any project feel connected. Healthy environments incorporate appropriate camaraderie-building events and attitudes, fostering a sense of connectedness and accountability that goes beyond schedules and deadlines.
7. Transcend insularity: The most effective collaborators will know that the strongest parts make up the strongest whole. Workgroups have a tendency to silo. But the workplace of today is best served by operating without boundaries. So instead, make collaboration the goal and hold each member of the team accountable for their participation.
Sustained dialogue, frequent opportunities to connect through technology and a mutual sense of purpose will help collaboration become second nature. Look for common ground and emerging issues of mutual interest, and encourage team members to connect and discuss.
Don’t pretend to be a project manager when what you really need to be is a Project Leader. In my experience, a Project Manager should only be a title you put at the bottom of your email signature. Project Leaders deliver successful projects.
A Project Leader is a person that puts aside self-interest in favour of the interests of the organisation, stakeholder, and team. A Project Leader does not try to manage the team by telling them the tasks that they need to complete or when to complete those tasks.
A Project Leader sets out the goal and then watches the team fulfil that goal. A Project Leader guides and nourishes a team in order to make sure the project is successful. A leader’s role is to support the project team and stakeholders in becoming self-sustaining and evolving in a positive manner. A Project Leader’s job is done when they are no longer needed, and the project, team, and stakeholders are running on autopilot.
Planning and executing any type of organizational change must begin with an understanding of and respect for the office culture. This can be especially difficult in environments where the culture is resistant to change. Often, higher-level managers will find lots of excuses for not making a change, usually couched in the triple constraint: The change will be too expensive, time-consuming or out of scope.
To begin the change process, especially if the change involves moving from a traditional Waterfall methodology to a more iterative or Agile approach, a project manager must be ready to counter the objections related to the triple constraint. Sometimes, the best way to do this is by example: Use a small, non-mission-critical project as a proof of concept. Measurable success using an iterative approach on a small project can go a long way toward organizational acceptance.
It is important, not only to start with a small project, but also to start with small changes. Rather than adopting a new Agile methodology, it is easier to introduce an iterative approach. For example, instead of instituting Scrum with its ceremonies and artifacts, why not try organizing the development and testing into sprints? Scrum-but isn’t necessarily a poor excuse for Scrum; it can lead the way to adopting Agile development.
Finally, it is helpful to find an “angel,” a senior-level executive who is not resistant to change and is open to and supportive of Agile or the iterative approach. The angel will be the senior manager who gives the go-ahead and supports the proof of concept. Resistance to change within an organization comes from change-resistant people, and when change is supported at the highest levels of management, eventually those who are resistant to change will buy in or leave the organization.
Remember, you are either part of the solution OR part of the problem!
Two things I hate; being late and tracking my time. Last night, my cousin the lowest part of her week is when she has to track time. What makes time tracking such a drag?
Why Employees Hate to Track Their Time – And What You Can Do About It
My company sells employee time tracking software that automates client billing, project accounting and payroll. We have implemented these systems for customers repeatedly where the employees previously were unaccustomed to accounting for their time. Occasionally this has generated some intense emotions. Some people really don’t want to track their time even when their managers are very firm.
Why is this? Why do people find tracking time so unpleasant, or even maddening?
And how about you? Do you like entering data into forms? Why or why not? Is tracking time any worse than filling out other forms?
My experience has shown that it often is for several reasons.
Reason One: Reporting time can threaten status. For salaried people, especially if they’ve been employed earlier in their life in an hourly “time clock” environment, reporting time can make them feel demoted. Conventional wisdom (that I disagree with) is that “professional” people are more trustworthy and less in need of supervision than “blue collar” people.
Reason Two: “What if I find out that I don’t work as much as I like to think?” Some people, often the most productive people, garner self-esteem from the large number of hours they work. But sometimes they’re not sure if they believe their own braggadocio and the thought of finding out the truth is scary.
Reason Three: Time is an imperfect metric for effort or productivity. Knowledge workers know that managers, who have the power to reward some people over others, often forget the vague and aggregated metrics of real productivity in favor of some simple numbers that are tangible, like time records. Managers may take the easy path of rewarding based on time spent rather than develop more subtle and appropriate metrics of real productivity. (Hint: don’t do this)
Reason Four: “I’m too busy” The most responsible and busy employees – the most productive ones whose time is in highest demand – will, sooner or later, always have to stop doing the primary mission of the company to fill out a timesheet. The star employees tend to procrastinate regarding this task, subordinate it or even refuse to do it. Or worse, they’ll create flawed records. On the other hand, the malingerers and marginal producers will often create perfect time records and never submit them late. This fact of life creates an impression in the minds of both that the whole exercise is worthless.
Reason Five: “I’ve procrastinated too long – and now I don’t remember what I did last week.” Procrastination results in useless time records. Who remembers what they had for lunch one day last week? When information – which was mostly made up – is eventually recorded about how much time was spent and on what, it often tends to understate the real accomplishments of the workweek. Reviewing this record can be demoralizing.
So – newsflash – it’s an imperfect world. And people hate tracking their time for many reasons. But how can you possibly run a project oriented organization, especially one that bills for it’s time, without time accounting? The answer is that, in this increasingly competitive world, you can’t, at least not for long. If you don’t get every hour billed that should be, or if you don’t know which projects are profitable and which ones aren’t, you’re going down. Hard. Because somewhere in your numerous and growing array of competitors is a company that’s getting it right. Your only choices are to follow or fail. Or you could lead – and be the first one to get it right.
So let’s look at some ways to overcome all this employee resistance to time tracking.
Education and Buy-In: I am a free market capitalist. So naturally I always think that the most effective way to get people to do something is to make sure they understand what’s really and truly in it for them. And there must be something – something that matters – in it for them.
• In the case of payroll for hourly workers, the desire to get paid fairly for every hour they actually work provides the incentive.
• In the case of billing automation, it’s revenue for the company (i.e. a successful company). Most people can understand this, and they care about the success of their company. If your employees do not care about the success of your company, timesheets won’t help you. You have to go back to the basics of creating a moral and compelling vision of how your company helps humanity (or fluffy bunnies, or whatever.) In the absence of having that strong vision, “bonusing” employees for their success in some intelligent way is usually helpful, although often fraught with opportunities to misstep.
• Project accounting is more abstract than payroll or billing. If done badly, it can lead to unnecessary overtime, stressful blown schedules, bad estimates and cancelled projects. Relating specific examples from your company in which good time collection could have prevented problems helps to get employees on board.
Adoption Dashboard: It helps to include graphs that clearly illustrate which departments and people are entering their time consistently and completely, and which are not. This helps managers understand early on who they need to badger about getting their time recorded, or who to reward for doing a good job in this area.
Phased Rollout: Adopting a multiphase rollout approach that leads to per-person per-project profitability allows you to change the culture in more manageable steps.
Incentives: Linking bonuses or other benefits with complete data collection is often used in customer relationship management (CRM) tools to adjust sales commissions. The same can be done for other forms of data collection. My company, Journyx Inc., has a patent—we call it the ‘frequent flyer patent’—for automatically rewarding your employees on your behalf for timely time reporting.
Email Reminders: Getting an automated reminder when your time has not yet been entered produces results…usually! Some percentage of people will become more timely with their data entry via this method. But be careful about overdoing the number of automated emails that you send. People will naturally start ignoring them if you send too many.
Implementing Project Accounting: If you have more than five people in your organization and they are working on many projects or within many processes, it is time to start thinking about implementing time tracking. If you have 100 people in an R+D group and you’re not tracking time, then you’re wasting the lives and work of a significant percentage of your employees. You might have them working on projects that the market will not reward you for, which are over budget or otherwise in the ditch, and you don’t know that today.
The new mantra of IT seems to be “do more with less,” but how does that work in practice? Is it possible for CIOs to slim down their IT staffs and still meet the high expectations of business users?
To get the answers, we talked with a half-dozen CIOs who run IT shops that are small by design, with a dozen or so employees. Even more than their bigger counterparts, these shops are using cloud computing, SaaS and outsourcing to offload infrastructure tasks and focus on the essentials of the business.
“This is a golden era for small IT departments,” says Reed Sheard, CIO at Santa Barbara, Calif.’s Westmont College, who manages a staff of 15. “With the cloud, I can do things now that only shops with lots of people and money could do before. Now I can play at an enterprise level. It’s a huge opportunity.”
These leaders of small departments offer five pieces of advice that even big shops can learn from, relating to agility, prioritization, staffing and vendor management.
1. Small makes agility easier – sometimes
For the head of a small IT department, “the opportunity to be nimble exists to a much larger degree than in a multinational corporation,” says Sheard. “I can get everybody in the same room at once.”
It’s not just proximity to staff; it’s also the proximity to the business. “It’s our responsibility to empower the college’s larger mission. That proximity to the heartbeat of the organization is advantageous because I can walk across the hall or across campus in just a few minutes to have a meeting.”
That nearness helped Sheard in a recent situation. Facing exponential growth in storage needs, he initially thought about simply expanding the organization’s existing storage-area network, even though his team found the software to manage it increasingly complex.
Based on his own experience and insights from other college officials, he knew that offsite access into the legacy storage system was difficult. He started running the numbers and quickly discovered that for the same cost of the SAN and its needed expansion, he could just as easily move to a cloud-based storage system. “We were able not just to fix the problem, but to look two or three steps down the road” to where mobile access was going to be in increasing demand, he says.
There can be a downside to agility, however. “Because we’re small, we feel we’re more agile,” says David Cooke, director of technology at Altum Inc., a Reston, Va.-based developer of grant-management software. Cooke has an onsite team of 12 and an offshore team of six. “If an opportunity appears, we tend to go aggressively at it,” he says. “That can drag individuals in different directions.”
Cooke’s situation highlights a scenario that can be a challenge in a small IT department. “Getting a small department to adopt process is tricky, because the tendency is to want to turn on a dime. You have to draw a fine line on how rigid the processes are. We have more processes in place than most companies our size, but they’re probably not as robust as I would like.”
Takeaway for big IT shops: Maintain relationships with peers for better business insight, and remember that processes are there for a reason.
2. Small makes prioritization a must
With a small staff, there’s no margin for error when choosing which projects you pursue. “You don’t have the resources of a large company, so you have to prioritize,” says Chris McMasters, CIO at Honeyville Inc., which has an IT department of six.
Customers of the Rancho Cucamonga, Calif.-based food processing and distribution company include Frito-Lay and Mars M&M. “When Kellogg’s needs us to integrate data, we determine that as a business priority, and focus our resources on it.”
That also means CIOs of small IT departments need to be better managers. “I have to allow my staff to focus on that project and minimize disruptions,” he says. That means giving employees the latitude to say no, they can’t drop what they’re doing because another project already has priority.
“If you protect them, they can finish one project sooner and get to the next one faster. You have to minimize the noise around them,” says McMasters. The alternative is the IT department ends up with a long list of to-do items, and very few are done well.
In the city of Goodyear, Ariz., a suburb of Phoenix, CIO Dan Cotterman (who runs a department of 18) says each department creates its strategic and operational plans based on the city council’s strategic action plan, which specifies what projects they need to accomplish. Then IT builds its roadmap, which helps it establish priorities.
The city used to have a request process that was highly formal and involved triplicates of everything. Cotterman says he has tried to make the process more informal, with weekly meetings with city leadership. “When a request comes in, we see how well it aligns. Usually only a few fit neatly with strategic priorities,” he says.
Takeaway for big IT shops: Identify and maintain priorities so your staff doesn’t feel torn in multiple directions.
3. Small makes staffing harder
The same rules apply for both small and large IT departments: You need staff with both technical breadth and depth. But for a small IT department, breadth may be more important than depth since consultants can be hired to provide technical expertise. Even more important for employees of small IT shops are business savvy and collaboration skills.
“You can’t have silos when you’re small because people are involved in everything,” says Dale Denham, CIO at Geiger, a Lewiston, Maine-based promotional products distributor with 750 employees and 30 people in the IT department. “I prefer not to hire people who only do storage, because they’d become so focused on storage-related goals such as I/O [to the exclusion of all else], they forget to focus on how a business unit accomplishes its goal.”
At the same time, personality conflicts in a small department can be disastrous to productivity. “They don’t have to love each other,” says Altum’s Cooke. “But we’ve had to get rid of people who were strong technically because they caused friction and there were personality conflicts.” His recommendation: Include more co-workers in the interview process to help gauge the compatibility of the applicant. Not a bad idea for companies of any size.
Randy Gross, CIO at the Downers Grove, Ill.-based IT industry organization CompTIA, has a staff of five. With a group that small, he says, if one person leaves and hasn’t documented his or her processes, “you’re in a world of hurt. Everyone has nuances in the way they configure systems, but human nature is not to let anyone touch your toys,” he says. His recommendation: a lot of cross-training, which is a key part of collaboration.
Read about the hottest jobs, industries and cities for IT pay in 2015!
“They have to understand that it’s not one guy coming after your job – it’s making sure the company is in sound shape [regarding business continuity] should something happen to one person. If you treat it like that, they’re more prepared,” says Gross.
When Gross brings on new staffers, they’re trained over three months in the most important disciplines, including networking, security and virtualization. “We’ll open up those areas one at a time to help them understand how they’ve been built, maintained, upgraded and expanded. Then we move to the next discipline.”
Takeaway for big IT shops: With DevOps and software-defined systems becoming more common, cross-training benefits everyone.
4. Take advantage of outsourcing options to focus on the business
The vast array of outsourcing options these days makes it infinitely easier to run a small IT shop, according to several CIOs. With outsourcing, you can craft an internal team that focuses on the business and craft an external team that focuses on technology.
“Cloud computing doesn’t necessarily reduce your resources, but it changes the skill set you need,” says Cotterman, who’s added three full-time positions to the city’s IT department in the past year, two of which are devoted to business analysis. “You’re going from an administration-heavy team to more business analysts, people who can explain technology and steer the business units down the path to the right solution. It helps us be much more customized to their needs.”
Scott Glenn, associate principal for IT Strategy & Operations at the consulting firm Hackett Group, says he believes strongly in this strategy. Maintaining a small IT department that’s good at keeping the data center running is focusing on the wrong thing – because anyone can keep a data center running.
“You need an IT department with an expertise in fixing the business issue,” he says. “You can change who supports the data center. You want people who understand the business in the IT department.”
Glenn stresses another aspect of having a small IT department focus on the business. “Technology changes so rapidly, it’s hard to keep skill sets refreshed,” he says. Internal IT teams can’t stay up on everything, and if they do, CIOs face having a really expensive staff. “Some resources are in high demand. If you hire them, they’ll hold you hostage for 30% more,” he says. “Let that be someone else’s problem.”
If you’re deploying ERP, hire people who are smart about that; ditto for social media or mobility. “You know what [the business] needs, but you need someone to help you understand the technology. Regardless of size, when you have that focus on primarily business-facing and new development, and not on hands-on keyboard support, you can get more done.”
Takeaway for big IT shops: What’s good advice for tiny IT shops goes doubly for big ones – hire IT staffers who know strategy, and source outside the company for particular technological know how.
5. Small makes vendor management crucial
CIOs who are outsourcing a lot of work must devote a greater proportion of their time to vendor and supplier management, whether that means individual IT contract workers or larger IT consulting firms.
Honeyville’s McMasters works with 20 contract workers to augment his staff. “I spend a lot of time on those relationships, because when we need them, they have to understand our business right away. Done right, it’s very powerful. They become part of the business,” he says.
When it comes to large consulting firms, “we don’t always go with the lowest bidder,” says CompTIA’s Gross. “You have to make sure they have the right kind of people and the right mix of people.” He’s witnessed the person with the most knowledge about a system leave the consultancy, which in turn left his company in the lurch. His recommendation: Don’t be afraid to use multiple consulting firms. “Some firms might say they know the whole Microsoft stack, but in reality, they don’t,” he says.
Takeaway for big IT shops: Whether working with individual contractors or large consultancies, maintain close relationships so you’ll have access to the talent you need when you need it.
How big? How small?
One question remains, of course, and that’s how big should an IT department be in relation to the rest of the company? No matter the size of the company, business has always searched for a balance in IT spending. In the past 10 years, reports from research firm Gartner have pegged the ideal ratio of IT employees to all employees at around 5%, although the percentage is significantly higher in some industries, such as financial services.
For small and large IT departments alike, there’s no set percentage. For small companies, what’s most important is that the staff isn’t so small that the departure of a key employee cripples the team or so large that staffers start closing themselves off into silos. While large IT departments have more flexibility in staffing, the same logic prevails: Focusing on cross-training and eliminating silos gives you more flexibility during inevitable staff changes.
Perhaps the best answer comes down to what helps the business most. Grow your internal team based on business needs, and grow your external team based on technology needs.
http://www.computerworld.com/article/2918493/it-management/5-lessons-small-it-shops-can-teach-the-big-guys.html?nsdr=true
When and how should a business analyst engage developers during the requirements definition process?
Engaging developers in the requirements definition process seems perfectly natural. After all, even if they are not explicitly involved in the process, developers do define all sorts of requirements as they build software. They make countless decisions (some conscious and some not) about what code is written and how. But generally, such decisions could be improved upon by making them more formal. Business analysts can provide the formal framework in which developers develop technical requirements.
Two common models of gathering requirements persist despite being counterproductive. The first and older model is built around the myth that software development is only about technical programming issues. Development is seen as a black art that can only be done by computer scientists. Thus, the entire development team is comprised of code-minded programmers who may or may not fully understand actual business requirements. This model is beginning to lift as the roles of business analysts, Agile project managers and testers grow more central to the development team.
A second mistaken model remains far more entrenched, but is no less dangerous. Some say requirements are the features of the software to be created. Indeed, developers do have a central role in defining how a product will work; but that actually is a form of high-level design, not requirements. Developers undoubtedly know much more than business folks about data structures, interfaces and other critical elements that must be taken into account for the implemented solution to work properly. However, these elements need to be built on top of a solid base of business-related requirements.
To supplement what developers know, business analysts provide a better understanding of what the business actually requires. Developers may have relevant and valuable business insights. However, that insight is not required for their role and is not their core competency. Work with business analysts first to attain a solid understanding of the business requirements. Then engage with developers to define the software requirements that meet the business’ needs.
The Best Organizations to Work For In Sports (What can we learn from our Athletic Dept that can be applied in OHR?)
So you want a job in sports, but given the choice, what organization is the best to work for?
The sports industry is incredibly competitive, with a high barrier to entry and an even steeper climb to the top. Those that have spent time working in sports know how often organizations turnover employees, whether it be due to the low pay, long hours, slow climbs up the ladder or any number of other factors that dissuade those who enter from having prolonged stays in the industry. Yet many within the industry do end up having long and fulfilling careers, and more often than not, their success can be traced back to the great organizations and leaders that helped shaped them both professionally and personally.
I set out to determine just which leagues, teams, agencies and other organizations within the sports industry set themselves apart from the competition when it came to factors such as employee satisfaction, work-life balance and career growth. I interviewed many dozens of individuals at all levels of sports, from entry-level sales staff to team presidents, as well as top executive recruiters and university leaders who have trained countless generations of top industry professionals.
The organizations that made the list are as different and varied as the industry they represent. Some employee just a few dozen individuals, others many hundreds. Among the areas of the business represented are professional teams like the Cleveland Cavaliers, leagues like the NFL, college athletics departments like the Ohio State University Buckeyes, marketing and consulting agencies like Premier Partnerships and data and research firms such as Turnkey Sports & Entertainment.
It should come as no surprise that during my research, many of the same organizations were mentioned time and again as being the best to work, and an equal many were often labeled as the worst. The differentiating factor between those who were spoke highly of and those that were looked down upon can be summed up in a singular concept – culture. Companies with the highest levels of satisfaction were also the one where employees felt they were more than just a replaceable cog in a giant machine, and where the primary focus of the organization was about creating a positive work environment rather than just the product on the field or the company’s bottom line.
There is no better example of the importance of positive organizational culture than the Arizona Diamondbacks, who were rated extremely high across all categories not just by the team’s actual employees, but also by individuals I surveyed in all areas of the industry.
According to Derrick Hall, the club’s President, “I truly believe that culture is our competitive advantage. We’re in an industry where early entry jobs are extremely difficult, the turnover is devastating and so you have to create a culture where your employees, not the customers, comes first. If the employee feels respected, developed and promoted, he or she will in return treat the customer the same way.”
Successful sports executives like Hall understand that great leadership is not about coming up with all the answers and then convincing your employees to follow your vision. Rather, it’s about having the humility to admit that you don’t have all the answers and then create an environment in which your employees can meaningfully contribute to finding the answers.
To this end, the Diamondbacks have created an operating environment where team employees have a tremendous opportunity to be heard. The club’s staff vote on an “employee of the month” who is then placed on the “Presidents Council”, which meets monthly to discuss key issues facing the organization. From groundskeepers to ticket sales to the front office, every staff member that works for the Diamondbacks has a real opportunity to influence the direction of the organization.
“We involved our employees in all aspects of the organizations decision making process, and make sure that no matter how things are going with the company, they know how much we value them,” explains Hall. “While we can’t control what happens on the field, what we can do is commit ourselves to treating our employees, coaches, corporate partners and fans better than everyone else in professional sports,” he adds.
The Diamondbacks also make giving back to the community a pillar of their organizational identity. The entire team partakes in a quarterly event centered around community service. This level of commitment goes far beyond just engaging with fans, and is at the essence of whom the team’s employees and players are.
“Nothing compares to the pride I have coming to work for the D-backs every single day – the culture within the walls of our organization is contagious, the way we give back to the community is admirable, our leadership team truly cares about the employees, and my co-workers are like family to me,” says Tiffanie Tallman, a member of the Diamondback’s Corporate Partnerships Department. ”But it’s the specific programs we have developed that prove how unique our company culture is to me: the D-backs Give Back League, the monthly all employee meetings including “On the Couch with DHall”, and the Most Valuable Partner Awards are just a few examples of our entire organization coming together to enhance the culture of the most amazing company I can ever imagine,” she elaborates.
Regardless of their size or purpose, each member of my list of Best Organizations To Work For In Sports has developed an incredible reputation in the industry for the positive way they treat their employees. I hope that my findings help both rookies and veterans of the sports business make an educated decision when choosing what organization to work for in a highly competitive and often unforgiving industry.
Jason Belzer is Founder of GAME, Inc. and a Professor of Organizational Behavior and Sports Law at Rutgers University. Follow him on Twitter @JasonBelzer.
DOES AGILE USE BUSINESS REQUIREMENTS DOCS?
Some use the term requirements management to mean the full requirements process, including identifying business requirements and evaluating their content. In my humble opinion, it is more appropriate to restrict the phrase requirements management to the mostly mechanical administrative activities of capturing, categorizing, keeping track of and controlling changes to requirements.
The two aspects do interact, and how they interact is especially relevant for the way Agile requirements are documented. In Agile, the product owner or customer representative typically defines requirements with user stories. A user story very briefly describes something of value to a user or customer and traditionally is written on an index card in the form introduced by Mike Cohn, “As a I so that .” Some teams also include their user story acceptance criteria (brief descriptions written on the back of the index card of how to tell the user story has been met) in the user stories.
Non-Agile development also documents business requirements definitions. Non-Agile teams could, but usually don’t, write them in a user story format yielding one requirement per index card. Initial business requirements documentation formats are not terribly critical for distinguishing between Agile and non-Agile. What happens afterward, though, tends to differ widely between Agile and non-Agile development.
A non-Agile group generally keeps track of all the written requirements throughout the duration of the project and captures written expansions/modifications of them. This process drives the business requirements document down to greater detail or otherwise clarifies them. Non-Agile often actively controls prospective changes to business requirements documents with a change control board or similar body. This body pre-approves requested changes and sometimes also confirms approved changes have been made as approved. Those non-Agile projects that use automated requirements management tools often cross-reference each requirement to where it is used in order to create a traceability matrix. Such a matrix helps confirm that each requirement has been addressed and that development is not creating artifacts that don’t tie to requirements.
There is essentially no Agile requirements document to manage the mental leap from brief user story to executable code.
In contrast, even though the Agile Manifesto does not specifically say it, many Agilistas believe Agile means not writing documentation. These leaders seem to favor writing no more than brief user stories and minimizing time spent on managing such requirements. Agile project teams on their own, without requirements management-type controls, frequently revise user story requirements. Typically, Agile teams break them into smaller user stories that can be implemented in a single sprint iteration. Without managed Agile requirements documents, the original versions can easily be discarded or otherwise lost.
Agile’s next requirements activity is referred to as “conversation.” The developer talks with various stakeholders to learn more about what to build. Typically, the conversations themselves are not recorded in any manageable form. Instead, the developer mentally processes the conversations, mentally designs a program to do whatever the developer thinks needs to be done, and writes the program as designed in his or her head. Often any written user stories are discarded by the time the code is implemented. Thus, there is essentially no Agile requirements document to manage the mental leap from brief user story to executable code. What could possibly go wrong?
http://searchsoftwarequality.techtarget.com/answer/Does-Agile-use-business-requirements-documents?utm_medium=EM&asrc=EM_ERU_40233989&utm_campaign=20150302_ERU%20Transmission%20for%2003/02/2015%20(UserUniverse:%201414302)_myka-reports@techtarget.com&utm_source=ERU&src=5364953
EFFECTIVE COLLABORATION achieves what no single team member can on her own. As business magnate Richard Branson said, “A business has to be involving, it has to be fun, and it has to exercise your creative instincts.” The best collaborations do this—optimize each person’s skills by utilizing suggestions from around the table, inspiring cooperation and creative buy-in from all involved.
Here are seven effective ways to create stronger team collaboration.
1. Aggregate and adapt: Any good project manager will bring ideas and plans to the table. The most collaborative will be highly skilled at weaving in the suggestions, ideas and goals of their team for a best-of fusion. Complex, multidisciplinary projects need to employ agile methodologies, involving innovation from all stakeholders and parties to succeed. The use of real-time data to help participants understand what is and isn’t working allows adjustments to be made on the fly. Successful collaboration is an aggregate of the best ideas while remaining adaptive and flexible.
2. Listen first: An effective collaborator knows how to bridge differing ideas into workable solutions. Getting to the root of any new concept or suggestion involves active listening, and listening actively to everyone with a stake in the outcome before mapping a course. Active listening includes giving feedback to confirm and clarify the information that was shared, and having a discussion in real time. A great collaborator will be able to respond most effectively once all parties have been heard. Team members want to feel valued, and being heard is where being valued begins.
3. Energize: The best collaborators assume that others are working smart and working hard. An effective and collaborative leader can bring inspiration and energy into a meeting room or conversation by helping team members feel valued. They sincerely express appreciation for a job well done. When criticism is offered thoughtfully and in the spirit of “your work is important to this project’s success,” effective collaboration becomes second nature. Talking about issues that need to be addressed can be done in a way that gets the team motivated about what’s possible. A motivated, energized team is a project’s strongest asset.
4. Remain open: Great collaborators always keep an open mind and know that brilliant ideas come from the unexpected. Openness is also crucial in building an atmosphere of trust. Workplace relationships are successful when employees are comfortable enough to voice concerns and make suggestions. Satisfied employees comfortably voice concerns and ask questions, and they know where to find the answers. Remaining open to new ideas, accomplishments and thoughtful critique empowers the entire team. The result: Faster problem-solving, healthier teamwork, greater trust and ultimately improved performance.
5. Be Transparent: The most effective collaborators are less concerned with titles and roles than they are with solutions. If a fantastic suggestion is made they give credit where credit is due, regardless of source. Furthermore, effective collaborators clearly define expectations and share information across the board. Clear and inclusive communication allows team members to know that they matter enough to be told the truth. Sharing details with the team increases a sense of workplace community, and adds to the spirit of collaboration. Teams thrive in environments that encourage trial and error and encourage participation.
6. Have fun! Plato is credited with saying that you can discover more about a person in an hour of play than in a year of conversation. An organization or project is more successful when morale, motivation and trust are high. Having fun together—from Tuesday lunches to a bowling night to meetings where humor and optimism have their place—make a positive difference in helping team members from different parts of any project feel connected. Healthy environments incorporate appropriate camaraderie-building events and attitudes, fostering a sense of connectedness and accountability that goes beyond schedules and deadlines.
7. Transcend insularity: The most effective collaborators will know that the strongest parts make up the strongest whole. Workgroups have a tendency to silo. But the workplace of today is best served by operating without boundaries. So instead, make collaboration the goal and hold each member of the team accountable for their participation.
Sustained dialogue, frequent opportunities to connect through technology and a mutual sense of purpose will help collaboration become second nature. Look for common ground and emerging issues of mutual interest, and encourage team members to connect and discuss.
http://www.projecttimes.com/articles/7-steps-to-improve-collaboration-in-your-team.html