Natasha's Mutterings

The Mystery of Hyper-V's Limit Processor Functionality? (Part 3 - Officially)

2008-06-02T13:58:00Z

I found out a bit more from the product group. It seems some legacy operating systems, like Windows NT 4.0, bugcheck if they perform a CPUID and have more than three leafs returned. The checkbox is there to allow us to try and get them working. So I was on the right track after all. I still think this functionality does limit what functions of the processor can be detected and suggest you try and leave it off if you can. It is important to note that the operating systems are not necessarily supported...(read more)

The Mystery of Hyper-V's Limit Processor Functionality? (Part 2 - Final)

2008-05-03T20:04:00Z

In this post I discuss how you can determine: 1. If your operating system is running on a hypervisor, 2. The processor feature differences presented for an operating system running directly on hardware versus a parent partition operating system on a hypervisor, 3. The processor feature differences presented for a child partition operating system running without LPF set versus one that does. ...(read more)

The Mystery of Hyper-V's Limit Processor Functionality? (Part 1)

2008-04-19T20:00:00Z

Recently I became rather intrigued with Hyper-V's Limit Processor Functionality (LPF) function. One little checkbox became such an obsession that I start wasting hours of my time trying to find out exactly what it does. The dialogue says, "Limit processor functionality to run an older operating system such as Windows NT on this virtual machine". That sounds pretty plausible because the newer multiple core processors with hardware accelerated virtualization were not around in the old days these operating...(read more)

Hyper-V MMC for Vista SP1 is released to RC

2008-03-26T06:21:00Z

Just a quick post today. Good news! The RC for the Hyper-V MMC has finally been released. It's designed to work on Vista x86 and x64 SP1. SP1 is required. Check out the Windows Virtualization Team Blog at http://blogs.technet.com/virtualization for more information Vista x64 Edition: http://www.microsoft.com/downloads/details.aspx?FamilyId=450931F5-EBEC-4C0B-95BD-E3BA19D296B1&displaylang=en Vista x86 Edition: http://www.microsoft.com/downloads/details.aspx?FamilyId=BC3D09CC-3752-4934-B84C-905E78BE50A1&displaylang=e...(read more)

Using the Office Live Workspace Beta

2008-03-25T14:49:00Z

My latest, most favourite tool on the web has to be Office Live Workspace Beta. It's an interesting extension to Microsoft Office and effectively allows one to create a free SharePoint repository for Word, Excel and PowerPoint document. It also provides add-in tools for Microsoft Word, Excel and PowerPoint to allow you to interact directly with your workspace, just as you would with Office SharePoint Server on an enterprise network. You can also share your workspace with others and allow them to...(read more)

Installing Hyper-V RC0

2008-03-18T09:02:00Z

So things are starting to get more than a little exciting. RC0 is finally here, and pretty much bang on schedule! Not so long ago I posted about installing Windows Server Virtualization on Windows Server 2008 RC0, now I'm posting about installing Hyper-V RC0 on Windows Server 2008 RTM. That's a lot of progress in a short time. It really looks like Hyper-V is going to ship on time! Before we start it is important to bear a few things in mind: All virtual machines/child partitions created in the beta...(read more)

Practical Best Practices for Infrastructure Projects

2008-02-26T03:43:00Z

In the many years I've been consulting as a Lead Technical Consultant, Architect and Engagement Manager there are a number of things I've learned from the school of hard knocks. Many things are obvious, and some less so. We can often find methodologies and material about how to run projects effectively, but rarely have I seen anything that discusses infrastructure design and implementation that includes information about how customers and consulting organizations can work together more effectively. This is a rather troubling situation, as many large enterprises work with external organizations to get projects delivered.

In this entry I'll discuss some of the main areas of concern I encounter in trying to enable my customers to operate more effectively. I'm focusing on the practical issues I encounter, rather than rehashing project management disciplines and methodologies. While those are important there are better places to read about them than on this blog.

1. Understand what an infrastructure project is?

Sounds obvious doesn't it, but most of the time it simply is not so. When I speak to customers, and even my peers, at the company I work for an Infrastructure project is usually some kind of storage, file and print, OS deployment, software distribution or messaging project.

Rarely do people consider that infrastructure, more often than not, provides the non-functional elements of an application development project. Some of my customers get it right, but most do not. Developers are not infrastructure people. They are more concerned with making it work, rather than being focused on redundancy, high-availability or operational environments. And rightly so! The problem is many people expect that developers can run SETUP and get things going, so they don't bother initiating an infrastructure project or sub-project in application development projects. This often leads to fantastic application development work not translating to success because the infrastructure belt and braces are simply not there to deploy and run the application successfully.

2. There is no such thing as a perfect RFP

Many of my customers create requests for proposals (RFP). Although this is an exciting time in their lives, and involves lots research and due diligence, the actual project delivery that results from the response they choose to ordain fails miserably. Most of the time it's because of simple things that could easily be corrected in their approach.

Firstly, try to remember that when you are creating an RFP you are asking an external entity to walk down a road with you. In partnering on any project of significant complexity it is better to understand what this might mean.

Be realistic with your deadlines. You might believe you can put pressure on external entities to help you deliver on your goals, but if you're doing so because you didn't put adequate planning in place or because you procrastinated it is unlikely anyone you partner with is going to be able to deliver in six months what you had to deliver in two years.
Give out as much information as possible. Many of my customers host a single RFP briefing session. These are normally one to two hours and they tend to talk through most of them with a bit of lip-service to questions external organizations that are responding may wish to ask. I think the question window needs to be longer. Consider who benefits from that the most. Why would a customer not want an organization to be genuinely interested in getting the best result for them. Clarifying questions are critical to providing a response that meets the actual needs.
Be sensitive to competitive advantage. Consulting organizations thrive on their IP. Its the secret sauces that gives them their competitive advantage. Often the very questions that make the most sense to be asked are simply not because the customer that issues the RFP insists on sharing all questions and answers with all parties. I recognize that some questions are obvious, such as, "how many workstations are affected by this project," and the customer may not want to answer those multiple times, but others are not. Consider that you may want to be engaging with an organization who is really prepared to think through the problems and resolve them, rather than an organization who grabs at IP and provides the cheapest bid. It's a tough balance to strike, but perhaps consider allowing people to ask questions in a way that they need not worry that their competitive advantage in IP is not thrown out of the window. Perhaps giving them the opportunity to ask up to five questions that will receive confidential answers may help out a bit.
Be prepared for detailed discovery. RFP responses only go so far, and they're only as good as the questions asked and the respondent's understanding of your organization. They can't possibly be perfect, and in many instances should not be considered to be binding obligations. At best you'll have a good feel that their technology will fit and that the chosen organization will walk down the road with you and deliver what you need. Let the chosen respondent do a detailed discovery after they are chosen, in order that they can provide more specifics with a more detailed budget. That way there will be no surprises half way through the project and you're more likely to succeed.
Do a proof-of-concept if you're battling to choose. Don't be afraid to request your short-list of companies to do a proof-of-concept (PoC) in your environment. Often the companies that are most likely to deliver will be baying for the opportunity. In doing so you will gain more confidence in choosing the correct supplier. Of course there is a caveat. You will need to plan and budget appropriately for your RFP. There are 'hidden' costs to an RFP you may not be thinking about. If a PoC is to be run in your environment you will probably need to have space to do so, connectivity, power and systems in places that can represent your environment to the degree that you can be confident the PoC is not a smoke and mirrors demonstration. If you're going to do it, do it properly.
Price is important, but... don't expect a Bugatti Veyron for the price of a Volkswagen Golf. Furthermore, don't expect a Golf to function like a Veyron! Price is always important, but be very conscious of marrying your executives requirements and perceptions with the solution you have chosen. If you promised them the world a few years ago, and then issued an RFP just before your delivery deadline it is highly unlikely you will have the budget or time you had then to deliver the Veyron you're still selling them now. The best result at the best price only comes from proper planning and a distinct lack of procrastination. You might believe you can put pressure on suppliers, but is unlikely what you get will ever fit one hundred percent.

3. Be Realistic

Now that sounds silly. It is a project and it has to be realistic. Unfortunately often this is not the case. There are a few things that we think are simple at the outset of a project, that simply end up derailing the project, and most especially the project schedule.

Understand the real risks. Don't outsource problems that cannot be resolved internally. Most often the problems I'm referring to here relate to internal politics, budget, management boundaries and business complexities. Put simply, if you don't have buy-in from key stakeholders for your project and you don't have the budget to do it, it is unlikely you'll find an external organization that can navigate the business complexities and also be cheap enough to solve your budget woes. Good consulting organizations can often help with one, but that will generally come at the expense of the other. Good resources are simply not cheap, but they're often more politically astute.
Understand your IT Rhythm of of the Business. Most large business have a IT lifecycle they adhere to. This includes budget and planning cycles, upgrade cycles, change request windows and freeze periods. In setting deadlines it is critical organizations consider these time periods when they start setting project deadlines. Do it up front. Don't suddenly be surprised by an external organization challenging your deadlines because you didn't plan up front. It really is not their fault.
Understand what you bring to the project. Your chosen supplier will be very dependent on internal staff contributions from your organization. This may be something as simple as input into workshops or document sign-offs, or more complex like working day to day with your project management office, depending on your company for procurement or for decisions that materially affect the project. In all cases these are critical dependencies for moving to the next phase of the project delivery. You will need to ensure the right people in your organization view the project with the right level of priority in order that you meet your project success criteria. It is far harder for external organizations to work with companies whose project sponsor is incapable of driving the right behaviour internally.
Avoid asking for extras before the job is done. The 'how about we do this and that' conversation really needs to occur when all parties are satisfied the initial project objectives are going to be met. I often sit with customers who suddenly see the potential of what they're implementing and then want more from it straight away. It's an exciting time, and it's wonderful to see the enthusiasm, but it's also important to remember what has been contracted and that the additional work you're requesting translates to project scope creep. Scope creep often entails more time, more budget and more resources. Scope creep discussions also often delay work in progress. Be careful, and expect to pay more at a minimum. Responsible consulting organizations will often point this out, but it rarely reaches a willing ear.

4. Architecture is good, but

An enterprise architecture is extremely important, I'm not suggesting otherwise. Often I encounter architects that create a desired state architecture for their organizations and then expect that it can be delivered within the businesses' constraints. Businesses have budgets and deadlines and require a return on their investments. Except in the case of legislative compliance, there is usually a requirement to compromise between desired state and the business constraints.

In implementing new technology, it is usually important to understand that it is positioned at a point in your roadmap to reaching a desired state. It is unlikely it will be the perfect fit. It will usually be the best fit for what is possible within the business constraints. Understand that and you're most of the way towards setting yourself realistic expectations of what can be achieved in the project you're undertaking.

5. Avoid Snake Oil

A huge problem in actually setting realistic project success factors is Marketechture. Often the hardball sales techniques employed by vendors and external organizations will look fantastic in a presentation or brochure, but may not translate to action or actual delivery as anticipated. We can all promise you the Earth with a "little" development work, but how many organizations can provide you that realistically. Take a careful look at what will actually work well for your architecture, get the technical and project people in your organization together with the vendor and external organization and do the research you can to try and make the best decision. Snake Oil rarely cures your ills.

6. Governance is not just a pain in the neck

Put governance in place for your projects, not just because it's a nice to have, but because it is critical to project success. As there is a lot of material about project governance available I'm not going into any detail on the subject here, save to say:

Put real decision makers into your governance structure. It is no use placing ineffectual or unempowered team members into decision making bodies on the project. This will just result in delays and frustration. Rather schedule decision making body meetings appropriately in order to ensure the decisions makers can be in the room when decisions are needed.
Insist on detailed project management and budget tracking. Sounds simple enough doesn't it. Yet it doesn't happen as often as you would think. Here's a hint. A spreadsheet of servers to be replaced or upgraded does not constitute a project plan; it's part of an implementation plan. Many of my customers work with external organizations and magically run out of budget at the eighty percent of delivery mark. It's usually because the budget wasn't being tracked effectively. Tracking the budget properly will help you determine if more is needed well in advance of it becoming an emergency. It will also ensure you meet your goals on time and within budget. Disciplined and well trained project managers will do this as a matter of course if they're given the time to do so. Ensure you support them in doing so.

7. Test the real deliverables

It's an obvious and short point, but a critical one. Spend time testing what you're expecting to be getting, not simply testing a product for what it should deliver. For example, testing an email system to see if it can send email from one user to another is probably a waste of time. Rather test it to see if it can send the types of emails you wish to send within the time frames you desire and on the bandwidth you have available. Test your customizations too.

Many companies will pay lip service about their project delivery methodology and will bang on about test leads and test cases, but many will also test the most rudimentary things only in order that they fulfil the test promises they made. This will result in expenditure, both in terms of schedule and budget, and will not help you achieve the desired results for your organizations.

Always allow your users to create the test criteria and participate in the actual testing. Never outsource those.

8. Failure to launch

Just as projects are about to be implemented, the failure occurs. It's great to have a perfect design, and have passed all the testing, but implementation disciplines and operational effectiveness are just as critical for your project's success. Once again, there is a lot of material about these disciplines out there. All I'm doing is highlighting those issues I encounter frequently.

Procurement needs to be done early. Be realistic though. Until a hardware design is completed you can't expect proper specifications for what is required. Put the hardware design tasks as close to the beginning of the project and create a finish-to-start task that kicks off procurement as soon as it is complete. Be realistic about your deadlines in this regards. Hardware procurement time frames and hardware shortages often cause delivery delays in the project.
Operations is part of the project. Operations is not something you tack on at the end of the project. That team should be an intrinsic part of the project from the outset. Their is nothing like a, "that will never work because the procedure for that is..." comment to derail the best laid plans. The more input you have and the more knowledge you disseminate to the operations team within your project the more likely you are to succeed. Furthermore, having the operations team in your project is more likely to help you understand what it will costs to train or acquire the skills necessary to operate your solution.
Real skill doesn't come from "knowledge transfer". Although on the job training and hand-holding is useful, all it really does is help operations staff become relatively proficient at the subset of the solution you're showing them. For staff who need to support the solution there is no substitute for formal training, certification and participation in creation of the test cases and performing the actual testing.
Operations staff are people too. Spend some time considering them when you're making a product choice. Although it might seem like a brilliant idea to implement a REXX-based application on IBM OS/2, you might have a hard time finding skills to maintain the solution or persuading operations staff to learn it because it's hardly a compelling step in their career. Attracting and retaining good operations staff to your organization is critical to keeping your environment running. In the short-term it may seem like you're pandering to their needs, but in the longer term it's actually an important consideration in maintaining your investment in the solution and its long-term viability.

I realize some of these points seem obvious, and others a little silly, but consider this. If they're so obvious and so silly then why do I encounter these issues in many of my customers constantly?

This post is governed under the site terms of use and by the Creative Commons Attribution-NonCommercial-NoDerivs license. Original work of Natasha Anne Mocke.You may republish this work as long as explicit credit is given to the author.

W2K8 RC0 - Windows Server Virtualization Installation Experiences

2007-09-27T03:44:00Z

So the day finally dawned, and RC0 was released. That same day I got word it would be okay to blog and show screenshots of Windows Server Virtualization.

So I went and bought a new laptop first because mine didn't quite make the grade.

While I was waiting for the RC0 download to finish, I thought I'd install and check out Windows Vista x64. I liked it so much I decided to keep it. And that's where the trouble started!

I thought I'd just eval it, so I just wiped the whole hard disk, made on partition and installed it. Because Windows Vista x64 can be on the same partition as Windows Server 2008 I was left with a dilemma. So to my first problem in getting Windows Server Virtualization working. I had to resize the partition, so I could create another! Simple you might think, but find a tool out there that does it. If you're like me and you know this was your own stupid mistake you'd rather reinstall everything, than buy a commercial tool (if you can find one that works on x64 Windows!).

After much hunting around I recalled that Linux had some tools to do it, so I found an openSUSE disc, booted it and edited the partition table. Fabulous! I then had two primary partitions, which was exactly what was needed for me to install Windows Server 2008 without destroying my beloved Vista x64 installation :)

It is important to bear in mind the following regarding the hardware you wish to use for Windows Server Virtualization (WSV):

It only works on an x64 based system with Intel VT or AMD-V extensions. That means you need to be able to configure hardware assisted virtualization in the BIOS! If you don't have the option and you know from the processor vendor's web site that your processor can do it, start hunting for a BIOS upgrade.

On my Dell D630 laptop the option in the BIOS is located POST Behavior/Virtualization - Enabled

It is also important to note that on some systems you may need to completely disconnect the power from your system after you've saved the BIOS settings. So if you're experiencing problems with the setup steps below, it may be worth a try. Some BIOS/CPU combinations do not reset correctly. Remember to remove the battery too if it's a notebook system.
You have to enable Data Execution Prevention on the BIOS. On AMD systems it's usually called No Execute (NX) bit and on Intel systems it usually known as Execute Disable (XD)

On my Dell D630 laptop the option in the BIOS is located at Security/CPU XD Support - Enabled.

So finally after all that, I got around to installing Windows Server 2008 x64 RC0. RC0 is important, as previous builds did not include the functionality at all.

After a successful installation I explored %systemroot%\wsv. In that directory there were two .MSU files called

Windows6.0-KB939853-x64
Windows6.0-KB939854-x64

I simply ran those in the order listed.

And that was it really. I was good to go.

The next steps were simple. I open Server Manager, went to the Roles Summary, and selected Add Roles.

Windows Server Virtualization was in the list! I simply selected it, and it began it's configuration.

Next, it prompted me for the appropriate network interface card(s) to use for my virtual machines

And then finally after a reboot, it proceeded to complete the installation and presented me with a results screen. Because my system was not connected to any network (it's a test system so why bother!) It warned me that Windows automatic updating was not enabled. It also gave me two informational messages stating that, "This is a pre-release version of Windows Server Virtualization", and also told me that WSV was installed.

To configure the environment and create a virtual machine all that was necessary was to access the management console via the server manager or the Start Menu.

After loading the Virtualization Management Console, I had to select my system name and then one right hand-side choose New/Virtual Machine. After a brief moment the New Virtual Machine Wizard appeared. It follows the same process as all wizards we're used to.

In the first dialog you get some "Before You Begin" information to read, which you can also disable for future running of the wizard.

Thereafter you are asked for the name of the virtual machine. You can also use the default folder for the virtual machine or create your own.

The third dialog simply asks how much memory you would like to allocate to the virtual machine.

The fourth dialog asks if you want the virtual machine to be connected to the network, and if so, which network card to send the traffic through.

Then the fun starts. The fifth dialog asks for the name of the virtual machine file, the location (again) and also the size. You can also use an existing hard disk, or attach a virtual disk later. Obviously using an existing hard disk has performance benefits.

You're then prompted for operating system details. This dialog is interesting as it is different than Virtual Server 2005 R2 or Virtual PC. It doesn't ask you which operating system! It just gives you the following options:

Install an operating system at a later time
Install an operating system from a bootable CD/DVD-ROM (you can also point to an image file)
Install an operating system from bootable floppy disk
Install an operating system from a network-based installation server

In my case I chose to install from a bootable DVD-ROM.

The last screen in the wizard is a summary screen. It also provides a check box to allow you to start the virtual machine once the wizard is finished.

And that's it!

I was returned to the Virtualization Management Console and right-clicked my virtual machine and chose start. Then nothing happened!

I had to right click the machine name again, and this time chose Connect... That opened a terminal server type session to the virtual machine and I was able to work within it.

Microsoft Certified Architect Certification Process

2007-09-02T19:22:00Z

So here it is, my first blog entry, finally!

Last week I got certified as a Microsoft Certified Architect: Infrastructure. It's quite an honor, especially considering just how different it is to other exam-based certifications out there.

In the case of MCA the process is a lot more rigorous and there are no exams.

As taken from http://www.microsoft.com/learning/mcp/architect/default.mspx, "The Microsoft Certified Architect (MCA) programs identify top industry experts in IT architecture. Microsoft Certified Architects (MCAs) have proven experience with delivering solutions and can communicate effectively with business, architecture, and technology professionals. These professionals have three or more years of advanced IT architecture experience; possess strong technical and leadership skills; and form a tight, supportive community. Candidates are required to pass a rigorous review board conducted by a panel of experts. The MCA credential was built by and for industry architects."

I had to write a case study on a project I had performed an architect role in. That's not a deep technical role by the way. If you look at the description above you'll see strong leadership skills are required too. There is also a lot more to it than that. The board that reviews candidates actually looks for specific competencies and many of them are not technology related at all.

Take a look at http://www.microsoft.com/learning/mcp/architect/archcompetencies/default.mspx for more details.

These competencies include:

Leadership,
Communication,
Organizational dynamics,
Strategy,
Process and tactics,
Technology breadth
Technology depth.

It's pretty pointless try to get the certification without understanding how to communicate with various stakeholders in a business including:

CIO's
CEO's
Architects
Operations Staff
Project and Program Managers
Technical staff

You will also need to demonstrate how you can work effectively in an organization mired in politics and embedded bureaucracy. It's a pretty difficult challenge, and you really need to have faced that multiple times in a project of the scope that you communicate with all the stakeholders in a business before you can be effective at putting together a case study.

So unlike MCSE and MCSD this is really not a technical certification. It is a bit in that you're expected to know what you're talking about and that you can act effectively in a technical environment, but it's also not because it's looking for a wealth of business and project expertise you just don't get by being a deep technical person and nothing else. There is absolutely nothing wrong with being deep technical; many people make a fortune doing so. This is just not the certification you should be chasing if that is what you are.

The board review process is pretty disarming. As much as you prepare and prepare, nothing really prepares you when you face your peer MCA's and get reviewed. They are looking for specific things and expect that you demonstrate them. Some things you might not expect to be questioned on but that are there include:

Solution Development Lifecycles
Operations (frameworks such as TQM, MOF, CMMI, CoBIT and ITIL. Also thinking about operations as part of your design cycle)
Architecture frameworks such as TOGAF, WSSRA, Zachmann

After putting together a case study, CV/resume and completing a self-analysis of your competencies you wait a little while with the MCA team reviews your submissions and determines if you're a candidate for the board review. The MCA process can stop at any time, and this is effectively the first point at which it can!

After you're selected, you're then informed of your review date, venue and time. You are then expected to prepare a 30 minute presentation on your case study. You will need to ensure your presentation includes your solution, your specific role in the solution (they're less interested in the project, than what you specifically did, but you still need to know the project details for the QA later), how you delivered the solution, what decisions were made and why and also demonstrate the competencies in line with what they are looking for.

They cut you off at exactly 30 minutes, so make sure you prepare your presentation properly and dry-run it multiple times! In my case I finished with 3 seconds to spare!

As a side note, but a rather important one, pick a case study for a project you know well. Pick something recent where you worked with as many of the stakeholders I listed as possible. Ensure the project you chose is not overly complex, because you're just not going to be getting the solution and the project dynamics across in 30 minutes. You do need to choose something interesting and challenging, but there is a fine line and you need to ensure you do not cross it. In my case I used a sub-project of a far larger project. I spent a couple of minutes defining the total project and then ensured they understood which piece of the overall project I was going to focus on.

The board then proceeds to ask questions that are mostly related to the case-study for 40 minutes. Each board reviewer has 10 minutes to ask what they like about your case study. You will need to remain cool, calm and collected and most importantly of all you better say you don't know something if you don't. They use precision questioning techniques and you can pretty much get yourself into a whole tangled web if you don't.

After the 40 minutes of questions, which is quite tiring, you have a five minute break while they strategize on what they'll be asking for the next 40 minutes questions round. If you're like me you'll walk out a little dazed and confused and completely unsure how you're doing. They are pretty poker faced so you will not get much of a read on anything or how well you're doing.

After that it's a free for all. Each board member has 10 minutes again, but they ask pretty much anything they like. So if they feel they'd like to drill into a competency or a depth technical area they do! It's even more daunting than the first round of questions and makes you feel like and even bigger idiot than before.

After that's over you have 5 minutes to say anything you like. In the case of my one other colleague that was accredited he did a sales job mentioning why he thought he was an architect. In my case I just said thanks and made some remarks about how I thought they could improve the room layout! Yeah I'm nuts. In my final five minute opportunity to ensure I got certified I chose that!

Anyway, I survived. Whether you pass or fail they give you amazing feedback from the process that can only serve to help you become an even better architect than ever.

A key learning for me was that the board members actually do want you to pass. They're looking for specific things and you must demonstrate your capability in those areas, but nothing they asked me was absurd or obtuse. They didn't try to pick holes in me. They were just interested in uncovering my skill areas, and I think they did it very professionally.

The certification is tough to get, but that's also part of its attraction. You cannot just learn some technology super well and get it. You need to have so much experience and faced many different situations to be able to achieve it. To me it's a breath of fresh air in an industry that is saturated with exams and boot camps pumping out inexperienced people. In a way the standard certifications are there to provide employers with a minimum set of standards for employing competent people. The architect certification is a master certification and demonstrates experience and expertise as well as demonstrating a number of soft skills and competencies. It's something you have to work for, not just learn for.

I hope these mutterings help someone, somewhere do well in their MCA review process. If it did drop me a note a let me know. I'd love to know I helped someone out there.