However, there is a core ideal to loyalty regardless of how various individuals may define it and the author included it in his original article from the dictionary definition – unswerving allegiance. Within the workplace, we tend to view loyalty through the prism of how it may have worked in the past, though I remain somewhat skeptical that our memories of workplace loyalty may be somewhat rose-colored in much the same manner that we tend to remember things from our own youths. We have this romanticized view that people stayed with companies and all was good from that time on. Much of this may have to do with how corporations were set up in the past. Older generations did not have the education available in earlier times that exists today and that levels much of the playing field in terms of workplace skills. In the past, those who obtained the high-level skills were, in many ways, guaranteed good employment by their respective companies because there were few alternatives. Whether these were always happy marriages and whether that loyalty is because there were few alternatives (in either the employer or employee viewpoints) is beside the point. The companies kept faith with their employees and there was little incentive for employees to go elsewhere.

Fast-forwarding to the current day, there have been significant changes which have altered the dynamic of loyalty and how it is viewed by both companies and employees today. While the millennial author viewed the idea of loyalty through the prism of generational separation, I think the issue is perhaps more deeply rooted in the changing environment that exists today with its continued and rapid technical advancements as well as the flattening of the educational background that has created a wider pool of those able to acclimate themselves to this environment. Those of the older generations view themselves as loyal to a company in the vain hope that such a perspective will be reciprocated by the company. Unfortunately, as the world has evolved and technology has rendered many manual tasks irrelevant, those who have not kept their skills up to date or have not similarly evolved into new roles with new knowledge have found themselves in increasingly untenable positions as far as job security. And, in those cases, no matter how loyal you may have been to a company, when you are no longer as productive, your loyalty is less likely to be rewarded by said corporation.

Does this mean that employees should not be loyal to their employers? No. Those companies pay the salaries of their employees which should demand a certain amount of loyalty. However, it is important to consider the definition of loyalty in this case. Employees should not be blindly loyal with a belief that the company is looking out for their best interest. But they should certainly work hard and do their best, recognizing that there is a reward in doing so. In addition to that, many companies offer opportunities for continued education in order to learn new or updated job skills. From their perspective, it is often easier to add job skills to their existing staff than to hire brand new staff every few years (or however often their turnover may be) and train them from scratch. In some ways, this should be viewed as a symbiotic relationship where both sides gain – the employer by having staff that is up to date on their knowledge and skills and the employees by adding to their skillsets which continues to make them valuable to their existing company (and others should they need to move elsewhere).

But having loyalty to the company should not be the sole definition. Instead, employees should recognize that they also need to be loyal to themselves and their careers. As a company is typically loyal to its stockholders and its own self-interests, the employees should be equally committed to their own self-interests and development. Loyalty to one’s career, advancing yourself as well as your skills, and staying employed should be the cornerstone of loyalty. Furthermore, loyalty to one’s own self-interest also does not equate to disloyalty to external interests (in this case, the company). Indeed, furthering one’s own development can be seen as a form of loyalty to the company whereby both employee and employer benefit.

As this business evolution has occurred, so have the perceptions by both employers and employees toward the idea of loyalty. Few people today work for the same company over the course of their entire career. Indeed, a decreasing number of people (particularly within IT) will work in the same role over the course of their career. This perception of loyalty and how it is viewed would be better viewed through the lens of how business has changed, the greater use of technology and how education has become the great equalizer by offering more people the same opportunities to achieve better employment in a culture and environment that relies less than ever on manual efforts. The perception that loyalty is defined differently by each generation is misleading. The reality is that the difference is due to the changing business environment and, as has been the course throughout history, the younger generations adapt to that change far more quickly and easily than older generations. It seems likely that in another 40 years, the next two generations will be arguing over the antiquated notions of loyalty discussed today.

I did not even realize that SQL Saturday was coming up in Richmond until I finally started seeing the hashtag #SQLSatRVA show up among some of the people I follow on Twitter and it dawned on me that RVA referred to Richmond. I looked it up and immediately registered when I realized that there were a couple of sessions I would want to attend. The problem was that I did this on Friday, one day before the actual event. The result is that I was waitlisted. I understood this to mean that I would only be able to attend if they had space open up at the last minute and therefore believed that I had missed my opportunity to be there. Therefore, I did not make special plans to wake up early on Saturday to attend.

So, imagine my surprise when I did finally wake up on Saturday morning, a little before 9, and saw an email in my inbox indicating that being waitlisted meant only that I might not be entitled to swag bags, possibly no lunch there (as that needed to be prepaid) and would delay my being able to get registered, not that I could not attend at all! So, I quickly got ready to go and drove off to the University of Richmond (which is a beautiful campus not far from downtown Richmond) where the event was being hosted. Unfortunately, it took me almost as long to find a parking spot as it did to get to campus. However, on the bright side, I anticipated this meant a well-attended event - and it certainly seemed to be that way!

Because I had not anticipated being at the event at all, I had not planned out my entire day. This meant that, by the time I got there, I had already missed the early morning presentations at 8:45 and was just a couple of minutes late to the next ones. It also meant that I had to register to get my name tag (which they couldn't print at that moment due to technical issues but I could have gone back to get later) along with the raffle tickets. Further, by the time I arrived, there were really no more swag bags for which the registrar apologized and I told him I wasn't worried as I was more interested in the presentations themselves and it was my own fault for being late.

There were several presentations I wanted to attend in the morning, including Andy Leonard's beginner SSIS presentation (I needed a refresher) and Karen Lopez's Database Design Contentious Issues - both of which were at 10 am - along with John Welch's Unit Testing SSIS Packages at 11:15. In the end, I went with Andy Leonard and felt very happy with both his presentation and being able to ask him a question afterward on something particular to a project I've been trying to find time to work on for the last couple of months and for which he gave me another way of trying to resolve that I hope to try later.

John's presentation was in the same room so I didn't have to go far for the next one. While I do not currently work with SSIS in any major way, I am very interested in it and was glad that there were several presentations on it. John's intrigued me as I, having come from an application developer background, was familiar with unit testing in Visual Studio for my applications but not with SSIS. He clearly laid out his arguments for doing so along with an example that gave me something to consider for the future so I was very happy to have been able to attend his lecture.

After that was lunchtime but, unfortunately, I had other things that I had made plans to do (because I hadn't considered that I'd be able to attend SQL Saturday in the first place) so I ended up having to leave halfway through the day. But I do not regret being able to attend this event in the slightest! I learned some things that interested me and that I hope to be able to use, I got to meet some very smart people in Andy and John, and it gave me a taste of something that I want to do again. So, even though I am just a project manager now, I hope to continue to learn and do more on the data side which can only benefit me and those for whom I work on a daily basis.

One final thought - I know that SQL Saturday is a great way to network as well. I was very fortunate to have met a fellow LessThanDot blogger at this event who traveled from out of town to attend - Samuel Vanga. It turned out he was also in Andy's presentation on Saturday morning and we had a chance to meet face to face so, along with all of the great learning, I was able to meet someone else face to face here on the LTD site! And I know that Samuel works with SSIS as well so I am looking forward to reading more of his future posts here on LTD on the subject.

For those of you who have considered attending a SQL Saturday near you, I highly recommend you do so. There is much to learn and do and, as I discovered at the one in Richmond, people will come from a long distance just to attend. Several of the presenters and many of the attendees were from out of town who came just for the event. For an event that is both educational as well as fun, there are few better ways to spend a Saturday!

When I was a developer, I worked on projects in both scenarios. Now that I work as a project manager (and occasionally as a business analyst depending upon the project), I find that the differences between them are more clearly delineated if still fairly nuanced. There are managers who see little or no difference between the role of a project manager and a business analyst. And there are those who see defined value in separating the two. In my experience, the breakdown tends to occur based on the size and scope of a given project. The larger and more complex a project, the more likely you will find a project manager implementing it.

What is the difference between the two roles?

First, a BA is typically expected to possess significant business knowledge with the ability to translate that knowledge into requirements from user requests to update or enhance systems (or even to create new systems, sometimes). They are also expected to have excellent communication skills in order to not only understand what the user is asking for, but to also know what they need but are not asking for. Then, they translate that into technical requirements that enable a developer to start their work without having to go back and forth all the time. In short, they are the agent for change to their organization.

A PM is expected to be able to manage and deliver the project from beginning to end. They are expected to understand what is needed from the big picture perspective while still being able to drive the smaller details through to completion. They coordinate all of the pieces into a single cohesive framework that they then execute to completion with the various stakeholders. They must be able to communicate at all levels to ensure that everyone on the project has the information they need to complete their tasks within a given timeframe and budget as well as the flexibility to handle the inevitable challenges that arise within every project. They are the ones to whom the project’s success or failure is dependent. In short, they deliver specific process changes to their organization.

And the difference between the two roles is defined thusly – the agent who is responsible for understanding and translating what needs to be done at the lower levels versus a true “manager” – for lack of a better term – who is able to see the big picture, put all of the pieces together, and ensure that any issues are handled as they arise with limited disruption to the project as a whole. While smaller projects often can be run by a business analyst or project manager because the scope will be fairly limited by definition, larger projects will often necessitate a true project manager who can truly manage the greater array of aspects that are part of said project.

I went back and looked at my own blog posts over the time since we first began LessThanDot. In total, I have 11 that I have written, 4 of them written in 2012 (which is more than I originally thought I had done). I have at least one that is currently in process from this past August after a conversation with fellow LTD'er Chrissie1 but not sure if I remember enough of what I originally intended to write that I will be able to finish it. That being said, though, I love to write and, quite frankly, am rather disappointed with the efforts I have put forth in writing more on this site. My own personal blog is not much better. But, I am setting forth a goal to write 12 new blogposts this year on LessThanDot - which would be 3 times my best year to this point. I do not think an average of one a month is unreasonable and it will hopefully prod me to produce better work than I have done to this point.

As Ted noted in his own post yesterday, the more we write, the better we become and, while I do consider myself to be fairly proficient when it comes to writing, I have also found that my skills have deteriorated from lack of use. Additionally, I know what I want to say but being able to do so succinctly, directly and ensuring that the reader interprets what I wrote as I intended for them to do so can be challenging and I hope to improve this. As a project manager, this is a very important skill as one of the major bugaboos of any project is miscommunication and misunderstandings.

Finally, while I do not typically set a great deal of resolutions, I will do so this year. In addition to more blog posts, I intend to do at least two formal training classes offered by my company to further my skills in project management. Frankly, there is still a great deal that I have not yet learned and I would like to be better so that I can handle whatever comes my way professionally.

So a Happy New Year to everyone!

And I'll add a caveat here - this is the second version of this particular post. I do not normally go through several revisions of my blog posts but it was necessary here as my first version was more an indictment of the project I was on rather than an impartial view of the failures that occurred and thoughts on how to make it better. Complaining about things may make people feel better in the short run but it does not help to provide long-term solutions to ensure the problems do not occur on the next project. One additional caveat is to point out that the experiences listed here on a fairly small project, only a half-dozen personnel and a timeframe of a few months (within a large organization, trust me, that is a fairly quick turnaround).

Perhaps the one key to any successful project is to have only a single project manager. This may seem a fairly obvious point but it is something that was hammered home on the aforementioned project. Indeed, after further reflection, this has not been uncommon in my experience though typically multiple project managers each handle various aspects of a given project, so it would be more like sub-project managers to a larger overall project. But the underlying point is that there should only ever be a single project manager at the top-most level and the delineation between that manager and any others should be very clear from the outset.

The next key is constant and open communication bewteen the project manager and all members of the project team. I will admit that this is a major issue for me and I work very hard to ensure that everyone has not just the information they need to do their piece of a project but also a view of the bigger picture. This serves two goals: they know exactly what they need to do but also gives them a piece of ownership of the larger project as a whole. It also helps to foster greater teamwork and accountability. When (not if, because the reality is that it will always happen) there is a problem within the project, if the team is already communicating, those problems can be addressed more quickly with fewer cascading issues as a result. For example, a problem on the part of one member of the team can be addressed by another if brought out into the open or a delay by one member can be addressed so that it does not cascade to the rest of the project. For projects with tight deadlines, a failure to communicate can prove disastrous.

Finally, there should only ever be a single source for the data needed for the project. Again, this should be fairly obvious but it is amazing how often failures can be traced back to this issue. There should only ever be one master project plan that the team uses to manage progress. And, if the project is a data-driven project, then all of the data should be in a single repository and not necessarily managed across a variety of applications or segmented by team/member. It does not matter if the plan is done in Project, Excel or some other project management software so long as everyone is operating off of the same plan. Correspondingly, any updates to the plan and/or data should be distributed to the entire team, even if the updates may not necessarily be applicable to all of the team. The purpose behind this (in much the same vein as the communication issue discussed above) is to ensure that nothing is missed and to allow everyone the opportunity for input that may actually help the project.

One thing that struck me as we went around learning from each other was the transfer of information and frustration with the lack of institutional knowledge that is easily shared among all of the different teams within our organization. Unfortunately, I do not think such a lack of instituational knowledge is something that is unique to my current company - I have felt it almost everywhere I have worked in my career in a variety of ways. From people who feel insecure with their position in the company and therefore keep all knowledge of given processes or applications to themselves and only share when forced to do so to those who seek to deny others the opportunity to achieve and promote themselves with a solution so long as they are able to claim the credit for the given solution.

Why do people behave in such a manner that is inconsistent with the success of the organization or the group? It seems self-defeating to behave in such a manner and certainly short-sighted both in the bigger and smaller picture. By not sharing knowledge and having a single base level from which everyone can grow and build upon, the result is often inefficiency, an inability to promote growth both on a personal and professional level and even chaos because there is no straightforward process from which everyone can operate. The company and the individual (or group) suffer needlessly.

When I brought this up with a friend, they brought up a valid point for why many people do this - there is no loyalty on the part of most companies to its employees so why should the employees have the sort of loyalty to the company that would enable it to succeed by sharing knowledge that would benefit everyone? In other words, it's a dog eat dog world out there and I need to look out for number one! And I can certainly understand that mentality on one level. But I believe that it is, in the end, short-sighted for the organization, the department and the individual.

While I am not a big believer in the "company" or offering my undying fealty to an organization that will release me in a heartbeat (I've seen it happen too many times in too many organizations), I believe in working both smart and hard to make things better for myself and others while I am at the company. And I absolutely do not believe that I should be the only holder of information! I view my job (regardless of how my job may actually be titled) as one cog within a much larger structure and a cog that can be replaced if it does not continue to provide real value. I also view my job - particularly those aspects which are either manual or repetitive - as something that others can do and constantly strive to find ways to improve what I do. And when I find ways that others can improve, I am not shy about pointing it out as I think it can help everyone in the long run. Some people respond positively and work to improve while others take such suggestions as a personal affront to their skills and refuse to adapt. Unfortunately, and more than once, those who felt affronted have been forced to look for other employment later. In the end, trying to hold onto a particular process or application and refusing to improve or adapt only does a disservice to both the company and yourself.

For me, I never want to be the only one who knows how to do something. While there are those who argue that it lends itself to "job security", it is more likely to ensure that, when/if that changes, the holder of that information will be "changed" at the same time. That doesn't include the fact that, in the event of a failure, you are the one who will be held accountable and responsible for fixing the problem - even when you are on vacation or sick. Besides, different perspectives on a process or application can sometimes prove beneficial both to the company's bottom line as well as the user's own knowledge base. I know that I sometimes see things only through a limited prism and have been surprised by the insight that others have provided on something that I thought I knew everything about and thus has allowed me to make it better. And this has proven true both as a developer as well as an analyst and project manager.

Finally, the more people who know a given process or application, the greater the spread of institutional knowledge that will benefit everyone involved. Sometimes, there is a need for keeping knowledge limited to a given few. But, for the greater success of both the organization and the individuals involved, it is always better to share that knowledge in recognition of the fact that it is a win-win situation for everyone involved.

To his credit, the developer did not point out what an idiot I was being. And when I realized what I was doing, I stopped immediately and apologized, explaining to him what I had done and that it was not my job to tell him how to do his. I think he appreciated that and we then discussed some of the ways that he could approach a solution. Now, normally I would not think a project manager would have to get into those details but I was curious to see his thought process and wanted to be able to contribute if I could. As it turned out, he had a solution that was pretty similar to my own thoughts with one exception where he found a more efficient method of handling one part of the process. In the end, he was able to build what was needed with a minimum amount of oversight on my part and little in the way of the sort of frustration that we have both encountered in the past. We had a solution on-time, on-budget (in this case, meaning it didn't take longer than we'd originally anticipated and thus no need for extra time/money) and something that did what the users wanted. We were both praised for our work on this project and everyone was happy. And for my own part, I learned what it means to step back from something that I didn't need to do and allowed the developer to do what he does best - develop a working solution.

It is worth pointing out that Alex Ullrich has also recently talked about something along this same line about limiting the developer and is worth reviewing as well. And Eli (aka Tarwn) also wrote an entry that covers a larger scope of projects and how to ensure they're done (correctly). Both are a little more comprehensive and certainly well worth a read!

I was recently asked to go manually update a bunch of Word documents with specific formatting. I hate to do things manually so naturally I sought out a way to make it go faster. Because of the formatting issues of the docs, a macro was not the most efficient method. However, I recalled that I could set my own keyboard shortcuts - woohoo! In MS Word 2007, it's actually pretty straightforward. First, click on the Office button in the top left corner. This will provide the base-level menu list.

On this menu list, click on the "Word Options" button at the bottom right of the menu list. On the list on the left-hand side, click on "Customize". You will then see the following:

At the bottom, click on "Customize" next to "Keyboard shortcuts:" in order to view all of the menu items and to enable the creation/modification of keyboard shortcuts. That will bring up the option to customize any keyboard commands. Below, you can see that I've updated the Highlight to use the default setting (Alt-Ctrl-H) which I found didn't work as I wanted and the Alt-Q that I added and which is easier for me to use. The same, obviously, can be done for any changes that you may also wish to make.

It is little shortcuts like these that create efficiencies and, at the end of the day, shorten the time I need to do things manually and enable me to accomplish more. Hopefully this will point the way to doing the same for you.

I had previously seen projects through the eyes of a developer (both on the database and application sides) and had not always understood the role of project managers and analysts as no project was delivered on time and as originally requested - often due to miscommunication (from my view). This is not to say that they were poor project managers or analysts, merely that what seemed to be fairly straight-forward projects often to go awry whenever they became heavily involved. Now, as I navigate through various projects working with developers and lines of business and trying to balance the needs and abilities of all involved, I have some additional perspective on the other side of that fence.

I think that having been on both sides of the fence that I bring some additional skills to the things that I do work on that, with luck, will bring about successful projects that don't frustrate the teams that work on them and happy end users who can use what is built. Not that I don't anticipate a variety of issues with each project but, as one former manager was notorious for putting it when we encountered issues, each one will be an opportunity to achieve and succeed. (Admittedly, though, there were times where I told him where he could stick those opportunities!) I hope to be able to provide my own insight on some issues here as I encounter them - perhaps as part of an ongoing series - with the hope that others may be able to also learn from them. Feel free to offer your own thoughts as well!

I'll begin by offering these small things to start:

- To my developer friends, remember that analysts and PMs often have to work toward a goal that is geared more to the end users and what they need, not necessarily what we as developers know would likely be a better or more elegant solution. In these cases, it is the immediate needs of the business that need to be addressed as their concern rather than the longer-term view. This doesn't mean to ignore those longer-term solutions, by all means you should provide them, but don't be offended if they don't want to go that route for whatever reason.

- To my analyst/PM friends, remember that developers are having to interpret what are sometimes the hazy requirements we provide them and develop solutions from only the pieces of the puzzle that they are given. When they offer alternatives that may be more than what is needed right now, it is often with a view toward the future and building a more comprehensive product that is scalable and better architected.

Indeed, the sense of anonymity is one that lends itself to the likelihood that people can (and will) be as brusque, impertinent, impolite or downright rude as they wish to be with little possibility of an actual confrontation - after all, you can simply turn off the computer whereas it is not so easy to walk away from someone you may have just insulted. Another sports writer who I enjoy following, Peter King (also of Sports Illustrated), also seems to get a fair amount of invective spewed at him by his Twitter and other online followers. Frankly, I'm surprised that his responses (at least via Twitter) aren't a little rougher - and I applaud him for taking things in stride from (seemingly) anonymous people who very likely would not say such things if they were face to face. The issue is certainly not any less among the technorati on various technical forums - and often is only managed through judicious editing by site owners.

But it is clear from Mr. Pearlman's that there is not truly the anonymity on the internet that people seem to believe. After all, if he could find just those two people who had been so rude to him, it's not inconceivable that almost anyone can be identified. It's not difficult to run a Google search on anyone, even by their online handle, and retrieve a trove of information that can be used to help identify them. And I am equally sure that there are more than a few other resources that can be used (both free and those requiring monetary means) to do the same. Frankly, there is no such thing as anonymity on the internet. All it takes is someone with the time and the resources to find you and there is little you can do. And the more you put on the net, the easier it becomes. As social networking continues to invade our lives and people exhibit increasingly poor judgment in the information they post about themselves, the sense of anonymity will continue to fade. The incivility that people exhibit under the mistaken belief that they cannot be found and confronted about such behavior is, frankly, incredulous to me. Especially so when, in the case of Mr. Pearlman above, both of his "attackers" actually apologized and admitted that their behavior was outside of their norm in the non-virtual world when they were found by their "victim".

The point above being that if people would not do such things in real life, then they should be wary of doing so online in the mistaken sense that they cannot be found. This is the reason why I try to always pursue a civil dialogue with any who wish to participate on this site (or anywhere else I may interact with others on the net). I was taught as a child to always be respectful of others - even if I did not always agree with them. Heck, on those occasions where I cannot always maintain the highest levels of respect, it is often with people who at least know me and can understand why I might react in a certain fashion. Worst comes to worst (and as I noted above), if things degenerate in some online interaction, I will (figuratively) walk away entirely. Why get aggravated over something in a virtual reality? The virtual world is increasingly becoming part of the real world and the consequences are no less - there are more than a few stories of people whose online social networking activities have held negative consequences for them in the real world. It is best to consider that there is no true anonymity online and to act accordingly - that everyone knows who you are and that there can be repercussions to what you do online as there are offline.